Table and Query Classes good or unnecessary?
Hi Das,
My opinion:
Table classes are very worthwhile and useful. I use them for inserts and updates and deletes, and I also use them to hold methods that are specific to the table.
Here is a simple example of what you can do with a table class: Asume that my logged-in user has a unique ID, and when they log in I store their ID in a task variable named tvUserID. Lets say I have a column in EVERY table in my database called INSERTED_BY, and I want it to hold the ID of the user that inserted the record. Lets also say I have a table class named tSuper which is set as the superclass for every one of my table classes. In the $insert method of tSuper I can now have code that says:
calculate $cinst.INSERTED_BY as tvUserID
Once this is in place, EVERY row inserted into EVERY table will have the correct INSERTED_BY value.
Query classes are much less useful and are limited in their implementation. If you need to return data from multiple tables using a join and you are in a SQL environment you are much better off creating a view in your SQL database, then creating a schema and table class in Omnis that points to the view.
Hope this helps!
Jim
>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
—
Jim Pistrang
JP Computer Resources
413-256-4569
<www.jpcr.com>
_____________________________________________________________
Manage your list subscriptions at lists.omnis-dev.com
Start a new message -> mailto:omnisdev-en@lists.omnis-dev.com