>It could also be much more convenient for the programmer if you provided
>some way of specifing sub-objects that were not demand-loaded. This is
>a little tricky in python because there is no convenient way to associate
>an attribute with a member variable declaration. One (far from ideal)
>possibility would be to prefix all demand-loaded member variable names
>with the word ``Demand'' (ie. embed the attribute in the name). One could
>then make a new class encapsulating the object ID, and give this class a
>``Get'' method that would lookup the referred to object (it could also cache
>the pointer to this object inside the object ID class so future Gets for
>the same member variable would not have to perform the lookup).
>
>In use this mechanism would look like:
>
>students = teacher.students.get()
>
>As opposed to:
>
>students = teacher.students
>
I had two proposals on my mind when I wrote this bit and ended up mixing them
together. The ``Demand'' attribute is not needed if the reference is packaged
up in a ``reference'' object that is de-referenced everytime the subobject is
accessed. Sorry for being confusing.
What I am proposing is functionally not very different from storing object IDs
as strings, but having these references encapsulated in a special object will
make them visible to the database engine (as well as to your python database
layer should you later want to implement load-on-demand or some such thing).
- David Ziegler (dziegler@hookup.net)