Table and Query Classes good or unnecessary?

Hey Das,

The problem of not understanding the use of table classes stems from
purely looking at it from a “what does this one function do”
perspective. From that perspective, yes you are right. The functions do
very little out of the box other then provide structure.

But their strength comes from that structure, something that goes for
almost everything in Object Orientation. When you don’t see how object
orientation can work for you, it just ends up working against you and
simple tasks seem to become overly complex and you don’t get what the
fuss is about.
Used correctly and suddenly seemingly complex tasks become very easy.

For me table classes have been paramount in saving time and effort in
building logic that talks to my database but if you look at my table
base class, so much has been added that is not supported by Omnis by
default. From dealing with sequence fields, to dealing with joins, to
automatically populating columns, to dealing with all sorts of things.

Inheritance is such a cool function of Object Orientation. It allows me
to add functionality to my base class that works with any table in my
database, and then implement any specific logic in the few places where
I need to do something that breaks that mold. Then someone who uses my
table class doesn’t need to be any wiser on how to use it…

That all said, if I could chose I would have done two things differently:
– I agree on the query classes especially on a database engine like
Postgres where you can just create views for any such use cases
– I would have merged schema classes and tableclasses to one class type.
I find having two classes for one entity annoying
But they are minor things.

P.S. one thing that I think must be underlined is that while I love
Object Orientation, I don’t necessarily find it the only true great path.
Indeed, when I see people struggle with its concepts, when I see how
Omnis Classic worked for so many by taking away those complexities, that
is the bit where I scratch my head and definitely concede with those who
find it troublesome.
If OO is not your thing, it will work against you, and if another
methodology of programming fits you better, then that should be
supported too.

Cheers,

Bas

On 3/3/18 7:21 am, Das Goravani wrote:
> I open this topic with this mood: Not to make a caustic discussion happen, but to find out what benefits these two class types give in a sober, calm way hopefully. Any responders are asked to keep it to the facts and leave out love of them, emotions, etc. Keep it only to the facts of what they do, what they offer, what can be done only with them, etc.
>
> Hi Mats.
>
>> Most love table classes. I find them redundant.
>> Table classes = extra layer of complexity and increase your amount of classes = larger library.
>> Query classes = a good way to make life harder.
> I’m glad you came out and said this. I have heard this opinion from another very learned member of the community, but off list. As a student of Omnis (again) I try to find what the deal is with table classes and all I’ve come up with so far is that they do a con() for you, not a great benefit, a very small one, and they put you inside the row which changes your notation syntax to match that reality, not a great benefit but rather another layer thing to remember…to code differently there verse everywhere else. I have heard from one who espouses table classes that he has very little code in his own table classes. This is about it so far on what I’ve learned. I see no impetus to adopt them therefore.
>
> As for Query’s, I hadn’t a use for them until I needed a list with fields from two tables in one list. I needed to define the list to include more than one table’s fields. I tried just defining the list but it won’t take schema classes as valid. I found the only way to define a list or row to contain more than one tables fields was with a query class. Am I wrong? How do you define a list with multiple table’s columns? Seems to me query is the only way. I must be wrong because I know there are some who don’t use them and they must need lists with more than one table in them sometimes.
>
> I would like to hear comments on this issue. How to define list/row with more than one table and not using a query seems impossible to me right now.
>
> In response to what else you said: I know about plain SQL verse using the Omnis function/commands $insert etc…at this point I use them mostly because I’m trying to get some distance covered, some features done, some app written, so I’m using what’s quick and easy. I know when I get into reports and more complex features I’m going to need to do joins and then I’ll be faced with query verse typing or choosing names from the catalog. I don’t yet see the harm of query classes, they seem like mainly a way to define a list with combined fields from multiple tables and that seems like a help not a harm. But I am not experienced at length with them or any of this, I’m an OmnisSQL newbie of about 2 months time max. I have an app largely written though…because I know Omnis the old from before.
>
>
> _____________________________________________________________
> Manage your list subscriptions at lists.omnis-dev.com
> Start a new message -> mailto:omnisdev-en@lists.omnis-dev.com

—
Kindest Regards,

Bastiaan Olij
e-mail: bastiaan@basenlily.me
web: www.basenlily.me
Skype: Mux213
www.linkedin.com/in/bastiaanolij

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