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

Posted by Gustaf Neumann on
Somehow, you made me curious, what your expectation was. But anyhow, thank you for the flowers!

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
to the reading list. The full library of xo* literature is at

hope this answers your questions at least partially

Best regards,
-gustaf neumann

Posted by Mark Aufflick on
Thanks for the answers Gustaf.

My expectation wasn't negative, I just hadn't realised how rich the openacs integration was, right down to creating the datamodels. Now if only it transparently handled data model upgrades like Malte was talking about ;)

I also didn't know about some of xotcl's features such as its meta-class implementation and design by contract support.

Posted by Gustaf Neumann on
Dear Mark,

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

Posted by Malte Sussdorff on
I can only second Gustaf's comment. The ::xo::db layer is great an works beautifully (XoDynfields is build upon that work). The missing pieces (although some only makes in context of dynfields):

- Extension tables: object_types can have extension tables in which attributes are stored. These are currently not supported by ::xo::db::*

- Support for multivalue

- Support for categories

- Attribute Elements (which are used to generate the form), taken from Dynfields

This is what XoDynfields has tackled, but if you need none of them or are fine with manually creating your forms, then off you go.

Also, if you want to use the website to extend your class then a proper user interface is missing (okay, im_dynfields provides that).