My findings on Table and Query Classes

I recently asked for input on Tables and Query Classes, now these are my findings after a little bit working with them.

I put some code into a Table Class and tested it. One method wouldn’t work, that I feel should have. As soon as I moved it back to the Object Class I’m using in a Window, it worked fine. That was of course a let down on Tables. It was hard to find appropriate code to put in the table class. I noticed in the manual it says “You never need to create one unless you wish to modify the built in methods, or add your own custom methods to the Table Class”. I find this very truthful and to the point. Given that Object Classes exist, there is hardly a need for Table Classes, unless you use the inheretence aspect, then that’s there and can’t be argued with.

My app is simple at this point, it’s young. So I dont have complex row and list based code to put in a Table Class at this time. If I did maybe I would appreciate them more. At this point it seems like effort to find code for them and put it there…and you’ve gained nothing that an object doesn’t offer. Again if you have big code, and it thus matters that you can type $cinst instead of the row/list name, then maybe there’s a reason. The different way you code in them may itself be a reason to use them if you are full time and have big code esp. relating to the row or list. Without these reasons, which I dont have, there’s little reason to make use of Table Classes.

I did have real need for a list with columns in it from more than one table. I needed a simple join. I made a query class of the fields from each of the two tables that I needed, I used that Query as the SQL Class that defined my list in this case…it’s a search results list…I then experimented until I found out how to make it work…that is simple…you need only worry about the WHERE clause, you begin it with your two fields that are keys in each table that match, with the equals sign between them, and then AND in your other WHERE clause logic, and the $select() notation will load the list as if you did a join in SQL and caught the list in a $fetch(listtname,kfetchall). The $select() notation knows that it’s a query class, knows the two schema classes involved, knows I guess therefore that any select using that list is going to be a Join, and is at least ready for it, because it’s doing that part for me.

This was a very good experience with my first needed JOIN and my first Query Class. I find the Query Class passed with flying colors, it actually replaces a lot of SQL in combo with the notation. The only thing I had to tell it was the names of the two key fields that equal each other, my fields filled in perfectly. So I can see using a Query class in the case of future needs for Joins.

If I was an adept at SQL and preferred typing my own instead of using the Omnis notation shortcuts, then I would find no need for Query classes at all. I realize a number of such programmers exist and some of them have told me Query classes are useless, a burden. I like them based on where I’m at in coding SQL and how I found that they work with the other shortcut features very well. Referring to the $select notation of a row or list defined by a SQL class and blessed by a Session Object. By the way if I hear a better word than blessed, maybe ‘activated’, I dont know, I’ll use it.

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