At 02:52 PM 4/30/2001 -0400, Andriy Shapochka wrote:
>Well, the concept of RelatedObjAttributes is potentially powerfull enough
>to represent any chains of relationships. But there are still some
>questions. How can it be defined by an user? Should it be defined within
>the root entity? Do we have to store information about attributes of the
>type in data maps? Will it incorporate just a string like
>"toDepartment.toCompany.toCEO.firstName" or an actual chain of
>relationships? Will there be a predefined order of SQL joins a related
>attribute is supposed to be resolved to or one will be able to control it
>(order, I mean)?
>
>Andriy.
I agree that this is a bigger issue. Maybe will even require a separate
design meeting. Anyway, as I mentioned before there can be these 3
scenarios (referred below as case #1, case #2 and case #3) when we want to
extend existing ObjAttribute:
1. In queries. To reference attributes that do not belong to root ObjEntity
2. In data maps. To map attributes in ObjEntity that do not belong to its
DbEntity
3. In queries and in maps. To build attributes more complex than just
simple table column
All 3 implementations might (and will) be different. Now I am concerned
about #1 for the purpose of query translation.
Answering your questions:
>How can it be defined by an user?
case #1 : Unlike all the others it has internal representation as a chain
of "ObjRelationship" objects. a constructor takes an array of
ObjRelationships specifying path + an ObjAttribute instance specifying
destination entity attribute. (I have some code doing that, I will check it
in tonight). Or a simple factory method in a class similar to EMaker (or
more likely whatever class will do string object query parsing) that takes
a string like "toDepartment.toCompany.toCEO.firstName" and converts to the
array form
case #2 - will be defined in the map
case #3 I do not know yet
>Should it be defined within the root entity?
case #1 above - NO, case #2 - YES, case #3 - it depends
>Do we have to store information about attributes of the type in data maps?
it is derived from the underlying Obj or Db Attribute definitions (coming
from the map) except for case #3, which I am not clear about
>Will it incorporate just a string like
>"toDepartment.toCompany.toCEO.firstName" or an actual chain of
>relationships? Will there be a predefined order of SQL joins a related
>attribute is supposed to be resolved to or one will be able to control it
>(order, I mean)?
Since all our query objects rely on the actual map objects in their
behavior (unless we decide to change it?) I am trying to stay consistent
and implemented case #1 with the actual ObjAttributes, not strings. Order
of those will determine joins, meaning that at present we do not allow to
tweak such things, although it might be a nice feature for version 2
Andrei
This archive was generated by hypermail 2b30 : Sat Aug 04 2001 - 16:21:24 EDT