Tim Cook wrote: > Hi All, > > This is different than the issues brought up by Rong in the Java > implementation. > > I brought this up before when reading the specs. But now as my code has > matured my fears are confirmed. > > Using Python: > > In an interface I define attributes of a class. In addition to some > meta-data I define the 'type' of that attribute. > > Code is here; > http://www.openehr.org/wsvn/ref_impl_python/TRUNK/oship/src/oship/openehr/am/archetype/?rev=0&sc=0 > > For example in IArchetype (the Archetype interface) I define ontology as > an ArchetypeOntology type. Now Archetype of course is supposed to > implement IArchetype. IArchetypeOntology defines parentArchetype as an > Archetype type. This creates a circular dependency when the interfaces > try to create a datatype based on a class that depends on itself. >
Tim, just to be clear - I believe the problem here is that you are having trouble serialising to and deserialising from a database (Zope in your case) from in-memory objects because some objects have circular references? If so, we need to be clear (or at least I do;-) about a few things: 1. some attributes don't need to be persisted at all. generally parent attributes do not need to be persisted, although they can. If they are not, you reconstruct the parent link on deserialisation. Your implementation may not even need the parent link but most do. 2 the difference between circular references in the object model, and circular references in instances graphs. When a circular reference occurs in an instance graph, you have to deal with it when serialising to any medium - and this is done by doing a 2-phase 'mark & store' traversal on the in-memory objects. This enables any complexity of circular links in an isntance graph to be correctly stored. 3. a self-reference in the class model, such as for DV_MULTIMEDIA doesn't necessarily mean a circular reference in an instance graph (and it doesn't in this case) - it just means there are 2 or more instances of the same class with references between. This should cause no problems at all for serialise / deserialise. The main reason for parent references by the way is for path processing code to traverse back up and down the object trees. In my Eiffel implementation of the ADL parser this is used ubiquitously. There are other approaches of course. Anyway, it won't hurt your openEHR data not to have these references! - thomas beale
