Doug, Tables, TMOBJS

Hi Andreas,

Nice descriptions from you, clarifies a lot. I have some thoughts though…

I use table classes for standard operations against databases, using the built in methods for insert, update and delete as examples. But I rely heavily on object classes in the form of constructs that I call data objects and process objects. A data object represents individual entities (as a variant of table class approach) and a process object represents a process involving more complex computations and aggregations, often involving more tables than one. Invoicing process object is an example of a usable process object.

Why do I use data objects instead of table classes?

One example can be the eventual need or ability to access certain information through services instead of direct data base access. This might happen in the future for certain types of entities such as customer information or product / asset item data in a system needing to interact with external systems. The table class approach cannot deliver the same type of transparency between a service and the client system as it can by db access routines. Using a ”black box” ”contractual programming” approach in this manner can prove to be a very big advantage in the future.

Secondly, the implementation of SQL workers and push that are separated from the current forms-centric approaches are more difficult to implement through table classes instead of using object classes for data management. In high-load environments the ability of using object classes through object references becomes important due to less load on memory and less computational needs when instantiate compared with $definefromsqlclass instantiation of table classes. In scenarios where an app server environment eventually can involve thousands of simultaneous users with heavy workloads the processing and memory costs for instantiation becomes an issue. My recommendation is to use session pools, SQL workers and for remote forms push as early as possible when developing solutions to safeguard that the solutions (even being fat client) can be additionally deployed on massive app-server systems. And to allow this flexibility one should look into an object-centric approach for interfacing with the data.

I prefer to write the SQL myself (or using tools like the SQL editor in Omnis etc.) instead of using schema classes etc. since it allows me to take the code and evaluate its potential for optimisation at the selected database server. Using the approach of statement blocks is a very good approach. It also allows for more efficient transfer of the SQL code into autonomous client implementations that are more easily managed by manual SQL code entry.

One can also minimise the use of return values by aggressively implement field references in the code. As described above – memory management is VERY important in systems potentially being used in app server environments and with high loads with many users. A table class of 10-50 kBytes might not seem like much – but in a system where each user has instantiated about 10 of these table classes and you have thousands of them constantly loading and unloading these table class instances there might be a challenge…

Take care, all the best…

Stene

_______

> 3 mars 2018 kl. 17:26 skrev Andreas Pfeiffer <apfeiffer@familiepfeiffer.de>:
>
> Hi Das,
>
> Table classes and object classes are very similar. You use them to instantiate objects so that you can use their data and methods.
>
> When you instantiate an object class you use an object variable and this is your interface to the methods that you implement there.
>
> When you instantiate a table class you use a list or a row variable instead. And then that variable is your interface to the methods you put into the table class but also the methods that Omnis already put in. Note: Those are hidden by default and you would need the interface manager to make them visible. I put an enhancement request to make them visible by default.
>
> So here we have the first difference.
>
> The next difference is that table classes can be bound to schema or query classes. When you then define a list or a row from them it also receives the column structure from the connected schema or query class.
>
> With an object class you actually need two variables in your window or remote form. One that represents the object and the other one that receives the data. In case of the table class we have only one variable that represents the data and the functions to load them. So a big plus and less overhead than an object class!
>
> i.e. Do myList.$load()
>
> vers. Do myObj.$load() Returns myList
>
> Also from the OO point of view you put any code that is relevant to the data handling into the table class. Hence you can just ask your list to do this or to load data or to save them.
>
> i.e.
>
> If myRow.$checkData()
> Do myRow.$save()
> End if
>
> vers.
>
> If myObj.$checkData(myList)
> Do myObj.$save(myRow)
> End if
>
> What you need to know is that when implementing a method into the table class you need to imagine that you are inside your row or list. That said $cinst is the row or list when you are inside the table class.
>
> For example the method $checkData inside your table class could be like this:
>
> $checkData
> If len($cinst.name)=0
> ;; name must not be empty
> Quit method kFalse
> Else
> Quit method kTrue
> End if
>
> Same method in the object class:
>
> $checkData
> Parameter pRow
>
> If len(pRow.name)=0
> ;; name must not be empty
> Quit method kFalse
> Else
> Quit method kTrue
> End if
>
>
> The method within the table class does not need the parameter because it is the data itself.
>
> Check out the new Omnis Academy I made recently: www.omnis.net/academy/online.jsp <www.omnis.net/academy/online.jsp> It deals with table classes and shows how to use them.
>
> Please note: I am not saying that object classes are not useful. I’d rather say that table classes are quite similar but better suited for data handling.
>
> Hope that helps a little.
>
> Best regards,
>
> Andreas
>
>
>
>
>> Am 02.03.2018 um 21:40 schrieb Das Goravani <das@goravani.com>:
>>
>>
>> Dear Doug, my questions are below your typing:
>>
>>> On Mar 2, 2018, at 6:02 AM, Doug Easterbrook <doug@artsman.com> wrote:
>>> We use oldRow extensively in the $update statement to find out what fields have changed for the key purpose of ONLY UPDATING THOSE FIELDS and making the app faster.
>>
>> HOW do you get the INFORMATION as to WHAT fields changed? I know I have to put old row in the update statement for it to work so I do it faithfully..but I don’t know how to query back what fields changed. Frankly at this point I KNOW what fields changed and I used a SQL UPDATE to list only the one field that needs updating, so I’m with you on only updating the fields that changed for network speed. But how do you get info back from the Omnis $update(old row) combo?
>>>
>>> Thats a clear example where the table class has benefit and the requirement to provide the old row for comparison purposes gives you the opportunity to optimize the SQL with possibility od significant performance gains.
>>
>> Aha, mention of Table class with the word BENEFIT. You actually don’t say what the table class does (here) that gives the supposed benefit. WHAT does a Table Class do in this scenario that an Object can’t do. I’m ignorant of the benefits of Table classes and posted just now a discussion provoking post to the list asking what are the benefits of table classes. You have to say in clarity WHY, WHAT, it does, that gives benefit over objects say. Some say tables are unnecessary while you and others say they are great, but I don’t know WHY they are great. Please tell this case’s reasoning. Why? What?
>>>
>>> it is for that reason, the TMOBJS xcomp thats out there in the wild and free to all has a static method that will provide you with the update statement containing only changed fields. Its useful.
>>
>> Please explain what you mean by Provide you with the update statement…. Does it use info returned from somehow and build you a SQL command that you paste into place? Does it work on the fly behind the scenes? Do you know where to download it and is it cross platform?
>>
>>
>> _____________________________________________________________
>> Manage your list subscriptions at lists.omnis-dev.com
>> Start a new message -> mailto:omnisdev-en@lists.omnis-dev.com
>
> _____________________________________________________________
> Manage your list subscriptions at lists.omnis-dev.com
> Start a new message -> mailto:omnisdev-en@lists.omnis-dev.com

Sten-Erik Björling
Enviro Data
Kyrkogatan 5A 2 tr
SE-972 32 Luleå
Sweden

E-Mail: s-e.bjorling@enviro.se
Mobile: +46-70-655 11 72
Wire: @stenerikbjorling
Skype: stenerikbjorling
iChat: stene@mac.com
FaceTime: stene@mac.com
Hotmail / Messenger: stenerikbjorling@hotmail.com
GMail: stenerikbjorling@gmail.com

______

This email and any files transmitted with it are confidential, may be legally privileged and are intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient, please note that any use, distribution, or reproduction of the contents of this email is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by return email and destroy all copies of the original message including any attachments thereto. Thank you.

Please note that we take reasonable precautions to prevent the transmission of viruses; however, we cannot guarantee that this email or its attachments are free from viruses. We only send and receive emails on the basis that we are not be liable for any loss or damage resulting from the opening of this message and/or attachments.

_____________________________________________________________
Manage your list subscriptions at lists.omnis-dev.com
Start a new message -> mailto:omnisdev-en@lists.omnis-dev.com