Well, no, I do not think you should make things more complicated than
they are now rejecting the current way most of relationships are
represented and manipulated. What makes sense though is to think about
introduction of a complimentary and more general class/bunch of classes
that explicitly represent the notion of Relationship between two or more
entities and have the following major characteristics:
1) They provide the functionality expected from a regular relationship,
that is given one or more data objects they provide one step access to
the corresponding related objects as a list, map, singleton, whatever.
2) The actual strategies of selection, updating, and management of
related data objects can be configured with custom qualifiers,
constraints, etc. at the level of Relationship types and Relationship
objects. From this prospective at present relationships are untyped (or
single-typed, should you prefer) named elements of the framework.
You see, in general this is most likely the only possible way to jump
over the limitations of the current untyped relationship approach. One
simply has to introduce the notion of rich types of relationships to
successfully deal with more complex issues arising in the realm of
knowledge representation and manipulation or otherwise to fall back to
the manual query running/dependency tracking labor. No doubt, their
implementation will present a great challenge yet may lead to something
of prominence and value.
Andriy.
Andrus Adamchik wrote:
> Well, relationships are first-class citizens in the metadata part of
> the framework. I don't think I'm ready to make them more explicit than
> they are on the DataObject side ;-) From the user perspective
> "relationship" property of an object should really be something simple
> - a List, a Map, another DataObject. IMO Cayenne will loose a big part
> of its usability otherwise. Of course as all the examples above are
> interfaces, internally they can be quiet sophisticated (e.g. currently
> a List returned for to-many is an instance of ToManyList that does
> lazy faulting, but potentially can do much more).
>
> Andriy, if you have something deeper in mind than I could grasp from
> your message (as you usually do ;-)), could you post the details on
> cayenne-devel?
>
> Andrus
>
>
> On Oct 18, 2004, at 5:22 PM, Andriy Shapochka wrote:
>
>> I think, the possible problem might be relationships are not treated
>> as first-class citizens in the framework. If one introduces a concept
>> of Relationships as explicit objects connecting DataObjects based on
>> certain criteria then it immediately becomes strightforward, at least
>> on the conceptual level, to define any specific types of
>> relationships parametrized with qualifiers. fetch limits, etc. and
>> use them to retrieve or connect/disconnect data objects according to
>> the application business logic. Basically, it is a classical method
>> vs. object architectural dilemma.
>>
>> Andriy.
>>
>> Andrus Adamchik wrote:
>>
>>> I was thinking about another approach - a relationship-level qualifier
>>> (like the one we now allow for entities), or even better - a full-blown
>>> SelectQuery to fetch a relationship (so that ordering and other
>>> parameters
>>> can be specified as well). However it is too limiting, as such
>>> qualifier/query will be shared by all instances of a particular entity,
>>> and customizing it at the object level is not easy.
>>>
>>> Looking for good ways to merge the two...
>>>
>>
>
>
This archive was generated by hypermail 2.0.0 : Tue Oct 19 2004 - 17:35:48 EDT