Forum OpenACS Q&A: Re: some basic xotcl and ::xo::db questions

The only automatic bulk queries currently supported are to select a subset of the available objects. In these objects, references to other objects are just numeric IDs, which of course can be selected one-by-one (not the most efficient approach in many cases).

The problem is not to say "a slot is an id referencing some other object" (simple via subclassing), but the way how to say, what to do with the reference, in which cases should the reference resolved (transitively or not), and what to do with the referenced objects in general.

However, nothing hinders one to fetch the results of arbitrary SQL queries into a ordered_composite via "instantiate_objects" (see xowiki for several examples). In most situations, this leads to simple and efficient code. If used together with "::xo::db::sql select" then the code is as well portable (for most real world problems).

Concerning: "set forum_list [$user forum_posts]"
If you want to call a method of $user, $user has to have this method defined (normally, its class should have an instproc). If the method is defined it can either return the item-ids as tcl list, or it can be done in a way to return an ordered composite (e.g. via instantiate_objects)

Concerning: "how do objects get destroyed":
in general, XOTcl objects (and classes) can live the lifetime of the aolserver run in the blueprint (when created via -procs.tcl), or they can be created during e.g. a request. When an XOTcl object/class is created, and it is not supposed to live on, it has to be destroyed. xotcl-core offers the method "destroy_on_cleanup", which means that the object will be automatically destroyed when the request finishes (similar to global variables). If acs-objects are fetched via "get_instance_from_db", "new_persistent_object", "instantiate_objects", these are automatically marked to be destroyed automatically. These cover the most important cases.

I would as well recommend to add the xowiki tutorial
http://alice.wu-wien.ac.at:8000/s5-xowiki-tutorial/slides
to the reading list. The full library of xo* literature is at http://media.wu-wien.ac.at/publications.html

hope this answers your questions at least partially

Best regards,
-gustaf neumann

i am not sure, what Malte was talking about in detail (i have not looked into details about dynfields, i have no application that uses dynfields, for malte the situation is different in the po context). However, the b´db layer in xotcl-core layer has already some support for data model changes:

- In particular the xo-db-layer supports data model extensions, i.e. additional attributes or tables (if the extension is done via the object layer).

- The xo-db-layer does not support data model migrations (altering data types etc.). Here the problem is actually less the data model migration itself (one could drop the old data model and create a new one), but the data migration, where i have certain doubts that it is feasible to do it fully automatically. I am not sure, if i would trust such a mechanism.

-gustaf neumann