Table and Query Classes good or unnecessary?
I echo jim. Table classes are totally useful.
for a starter.
– A table class binds the query the the sql. If you want more columns in your list, just add it to the query. now you have more columns. Simple. easy to look at/document. done. Just add a column.
– A table class is associated with a data list. Data lists can be displayed in headed lists.
we have functions in out table class to do something like
— tell table class that it will be displaying in a list
— tell table class to show visible columns
— link a click on a header in the headed list to the table class to sort the list
— link a resize of a column in the headed list to the table class to have it remember what the column width is so necxt time the window opens, it opens at the same column width
— allow hide/show of columns in the headed list … and guess, what, next time that window opens, the same columns are visible
— same goes for the order of columns
the omnis code looks like:
— do list.$sort(column 5)
— do list.$saveSettings(refToHeadedList)
allows us to centralize data methods in a very convenient place in omnis. eg
makes code easy.
allows us to optimize code and make life fast
— I see you found TMobjs. we optimized the insert/update statewment to onlly transmit hcanged data . you can’t do that easily when you roll your own in a convenient way
you get smartlists — with the $history list. The $history list keeps the data as it was before you start making changes. so you can look at old/new values — and this is built in.
You can have table classes within table classes so make objects like invoices (although some people prefer objects with a bunch of table classes in them). Bas as talked eloquently about this …. and the point is simply .. table classes (even within objects) … are the best way to store lists of data.
Our application has some 3700 objects (menus, windows ,table classes, queries, reports).
I make a new table class for each window and a query. That way, if a client asks for a new column — I change just the query and never bother looking at any other code because I know all my features (sort, column saving, etc) all work and the data will be displayed in the headed list. so it saves lots of time.
think of a table class as a view of the data. its code clarity and separation and inheritance..
there are other reasons we use them .. far more. a some of it is performance.
see you at the third annual users conference
> On Mar 2, 2018, at 1:48 PM, Jim Pistrang <email@example.com> wrote:
> 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!
>> 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:firstname.lastname@example.org
> Jim Pistrang
> JP Computer Resources
> Manage your list subscriptions at lists.omnis-dev.com
> Start a new message -> mailto:email@example.com