Forum OpenACS Development: Re: xotcl object and adp pages

3: Re: xotcl object and adp pages (response to 1)

Posted by Andrei Mitran on 06/10/09 05:29 PM

Gustaf,

1: Many thanks for responding. Yes I am aware of how xotcl db_1row works for acs_objects. It is very nice and thanks for all the great work that you have put into it! It works great for tables I have control over. Unfortunately the application(s) that I am working on has nearly 2,000 tables across 5 databases. None of which are or can be acs_objects. Some of these tables are large 10's of millions of rows and I need sub second response for the queries. Raw sql performance is mostly good. As an old guy I continue to be amazed at how good most of the major relation database systems work if you have a decent design with good hardware (In my case 10's of GB of RAM, lots of processors, many independent spindles for data, indexes, txn-logs with large numbers of raided drives for each etc.) and you use indexes wisely.

I ended up using the information schema (data dictionaries) to figure out the columns and used a loop to create the instance variables. Not ideal – it would have been nicer to create the instance vars automatically from the select list of the query. Where there was a large number of columns (200+ and some of the columns are big 5k varchars) I resorted to using the select list itself or hand coding the instvar creation for specific problem queries. I was thinking of writing my own version of db_1row and db_0or1row called db_xo_1row to deal with this better.

2: Yes – extending the adp compiler is probably the best way to go. I am mostly using json/jquery/ext3 these days so I just have the class spitting out the appropriate json – avoiding the problem. If I can get a break from my day job - I might extend the adp-compiler and contribute it back if anyone else was interested – it would be handy for retrofitting some older code.

In general, using xotcl is helping to structure the code better and it is reducing the amount of code and queries needed.

I have another question: If I don't remember to destroy the instances created for a page it is not clear to me if I will have memory leaks.

Thanks for the help,

Andrei

4: Re: xotcl object and adp pages (response to 3)

Posted by Gustaf Neumann on 06/11/09 12:07 PM

Dear Andrei,

The method db_1row defined by xotcl-core works for all SQL queries, not only for queries on acs-objects. For example, acs_attributes are not acs objects.

   Object o -destroy_on_cleanup
   o db_1row . {select * from acs_attributes limit 1}
   o info vars

The same way you can use the tables of your own data model, use arbitrary SQL queries with joins, etc.. The same is also true for instantiate_objects. For both methods the instance variables are created as needed by the results of the SQL queries.

If you want to create XOTcl classes from the data dictionary - which might be useful or not - it requires more work and more detailed knowledge about the available schema definition. xotcl-core is able to automatically derive XOTcl classes from the schema definition of the OpenACS meta data.

If i can be of any help for the adp integration, or if the are some results that you can share, let me know.

Concerning object/class creation/deletion: Certain objects/class should persist in memory after a connection thread, some of these not. The objects/classes defined in the -procs.tcl files should certainly persist.

The situation with XOTcl objects and classes (which are technically Tcl commands) is pretty much the same as for other Tcl commands (e.g. the one generated by tdom). In general, temporary objects/classes can be destroyed using "manually" with the destroy method, or - the recommended approach - with the method destroy_on_cleanup. Most of the object creating commands in the xotcl-core SQL interface use destroy_on_cleanup. This is described in the API definition.

In the example above, the objects created by instantiate_objects are automatically cleaned up. Object o from this posting is automatically cleaned up, while the version of the first posting is not.