On Fri, Jun 6, 2008 at 7:24 AM, Fred Drake <fdrake@gmail.com> wrote:
Still another approach, if you're looking to create software support and the first isn't suitable, is to use fields that provide additional interfaces that indicate the nature of the references.
My application (and I suspect other cases will) need to do just this; a marker on the field eliminates the ambiguity. Schema and interfaces should allow for complete "domain modeling" in such a way that expresses intent of the business case, regardless of the persistence mechanism or implementation details underneath, so I think I'll continue to use custom field types marked with an IRelationshipField interface, and assume the built-in Object, List fields are only used for containment. The only thing I do not like about my direction is that it leaves ambiguity when working with code from other components/projects that do not share this assumption. For RDBMS persistence of schema-defined content, z3c.dobbin (for example) assumes Object fields are just foreign-key relationships, but the downside to this simplification is an inability to meaningfully interact with a simple persisted containment scenario (a complex object that has contained specialized child objects intrinsically part of the primary object; trying to serialize to JSON with clear recursion boundaries for example, would be difficult). In my application-case, I'm looking to do something similar, but hoping to do so with a clear bright-line between associations and containment. Note: removal of such ambiguity is helpful for the possible use case of schema/interface bootstrapping/generation from UML tools for model-driven-design. Sean