Unhappy in SQL Database World

[Das Goravani]

Dear Mats,

Thank you for your input, it is very interesting, I’m glad you posted it.

Using the plain method, do you put JUST the fields that changed in your statement, you don’t put all the columns of the table correct.. I’m wondering about verbosity and difficulty in handling long strings of field names.. your example I think shows one field being updated.. which in real world is all that needs to be updated quite often.. one field. Not whole row.. please comment on whether you always use just the fields that matter or whole rows, is it hard to paste in whole rows.. does it take up a very long line of code? 

Interesting that you found the ORM method not workable in the real world.. I am developing on ORM and plan on using it in real world.. but I do find it touchy.. it seems to get twisted and not work sometimes for no reason one can know… I have to reboot Omnis for it to behave again.. is that the kind of thing you encountered?  

I learn NO SQL doing ORM.. true.. you don’t do sequel, you do three statements, Insert, Update, Delete, that’s all you do, you never learn SQL.

It’s interesting to note that when Omnis converts your data for use with SQL in the Data Migration Tool they do not make schemas.. which means the MAPDMLTODAM functionality does NOT use ORM AT ALL but they must have programmed it entirely with the plain method of SQL… Interesting thought. 

The ORM method does only whole row.. which can be unwieldy.. I have very large rows on some tables and only need a few columns read or updated at times.. never is the whole row changed, never.. 

I’m so far doing “Keep CRB”, “Centralized Code”, ORM.. so I have update in only one place and it handles ALL tables.. this is possible with ORM.. I supposed it’s possible with plain method.. you have to have impersonal code, that handles all, not specific, so you don’t know what fields are to be updated for some given table that comes through for an update… so you do whole rows.. you have to.. you simply don’t know the specifics of any one specific save that occurs.. I like this impersonal centralized coding way.. you have your working main code in ONE PLACE ONLY.. you worry about one place only. I like that.. I also like that I can get specific and do plain way at some given location in the code that doesn’t fit into the generic model.. 

So far for me the ORM works if I do delete insert for update.. this is acceptable in my appp with my customers, my circumstances.. not being a business app, not on a mission at all.. a desktop entertainment app mine is.. low data loads.. low usage… very cool.. not hot.. 

I’m happy so far.. pleased with ORM.. 

It’s interesting that GRADUATED players like yourself, Kelly Burgess, Jerry Greenburg, all tell me they don’t like the “black box” ORM method and don’t use it but prefer plain method.. some people go so far as to skip table classes as they prefer the NO MAGIC way where they control exactly what goes on, and they can SEE their SQL they always say.. interesting realities

Thank you for your time and efforts in responding.. I REALLY appreciate it and I’m sure others do too.. there are intermediate people on this list who are quiet and don’t post.. but they’re here reading and taking it all in. They appreciate the content very much. 

Thanks

Das Goravani




> On May 12, 2020, at 10:32 PM, ADJob <mats at adjob.se> wrote:
> 
> Hi Das,
> 
>> I’m DONE with my conversion, if ONLY UPDATE WOULD WORK.
> 
> There is at least two options of update:
> 
> 1. The plain way (using object classes only)
> ——————————————
> Begin statement
> Sta: {UPDATE table}
> Sta: {SET}
> Sta: {”table_text” ='[pv_TEXT]'}
> Sta: {WHERE  ”table_id"='[pv_ID]'}
> End statement
> 
> Do STATEMENT.$prepare() Returns #F
> Do STATEMENT.$execute() Returns #F
> If flag false
> 	Do msg.$ok(STATEMENT.$nativeerrortext)
> End If
> 
> 
> 2. The ORM way (using row data in object classes)
> ——————————————
> Do pv_NEW_DATA.$update(pv_OLD_DATA) Returns #F
> If flag false
>    Set reference lv_STATEMENT to pv_DATA.$statementobject
>      ;error message
>    Else
> 	Quit method pv_DATA
> End If
> 
> ——
> 
> The plain way is more verbose and looks more ugly, but it is way easier to debug.
> The ORM way looks elegant but is way harder to debug. 
> 
> I tried to understand the ”ORM” way (tables), but I could not get it to work in the real world.
> 
> Though I use both, I prefer the plain way. It is way easier to understand. And you learn plain SQL. Not Omnis ORM with table classes)
> 
> The more auto-magically (table classes), the harder to learn and understand SQL.
> 
> FWIW,
> 
> /Mats
> _____________________________________________________________
> Manage your list subscriptions at http://lists.omnis-dev.com
> Start a new message -> mailto:omnisdev-en at lists.omnis-dev.com