Hi Holger,
First, I really appreciate you taking time to review Cayenne design. We
really need an educated fresh look at things. Now answering individual items.
>I do have a couple of questions and suggestions, in no particular order:
>
>- the main reason for the strong separation between DbEntity and ObjEntity
>that I could think of is the possibility to plug in alternative
>storage/persistence mechanisms later (OODB, JDO, Smalltalk-like image
>snapshot etc.) by means of different DbEntities - right?
In fact way back when we settled on this design, the main reason was to
make it easy to create flattened relationships (still pending
implementation) and such. Also there was a feeling that database and object
sides of the mapping are logically separate.
This is of course debatable, and I do not 100% agree, but this is what we
have now. Coming from the EOF background I was kind of opposed to it when
we were doing the original design, but I didn't have a strong argument
against. Recently I got one when trying to fix countless modeler bugs
caused by arbitrary map objects removal (remove db attribute that has obj
attribute mapped to it, etc.).
Well, I guess now we need to take full advantage from this separation,
including the stuff that you mentioned. I think TopLink has it this way? (I
am still a newbie to TopLink, but with my current job I have a chance to
become an expert).
>- am I right that there is currently no validation suport (as in
>validateXForY) or did I just overlook something in the APIs?
You are right. It is not there. We have no specific plans for it yet, so
there is lots of room for discussion.
>- Strings are evil! I beg you to please, PLEASE! change the APIs that take
>Strings as arguments to only use classes or proper Db/ObjEntities
>whereever possible. For example:
>
> -- DataContext.lookupEntity(String) -> lookupEntityForClass(Class) is
>IMHO much cleaner and does not clutter up your program with hard-coded
>mapping names.
>
> -- DataContext.registerNewObject(DataObject, String) ->
>registerNewObject(DataObject) - why not get the ObjEntity from the
>DataMap? If the DataObject's class is not registered there, it won't make
>sense anyway (AFAIU).
Using string entity names adds another level of abstraction. For instance
you can have the same class mapped to more than one entity. This is not
necessarily a good thing of course. So I tend to think that your suggestion
may be the way to go. Besides mapping directly to class as opposed to
abstract string name opens the possibility of mapping arbitrary classes,
not inheriting from CayenneDataObject - something that is really important.
>- ordered relationships! You might have read some of my thoughts on this
>on wo-dev/wo-talk; although some people think data ordering is strictly a
>'view' responsibility, I still feel many kinds of data are inherently
>ordered in some way. It would be very cool to have automatically ordered
>server- and client side to-many relationships! These should ideally be
>configurable in the mapping (DbEntity/DbRelationship) with the
>corresponding effect (maintained ordering on insertion) on the Obj side
>of things. I have this working in EOF and it's _great_, although
>admittedly only half-baked since it doesn't take to-many array
>modifications into account. With pluggable relationship classes/array
>subclasses this should be a no-brainer in Cayenne.
Yes, I absolutely agree. We had this feature in our initial "goals
statement" way back. It is just being postponed all the time.
>- similarly, model-specified (but user-overridable) relationship
>prefetching would be helpful. Why should my application hard-code prefetch
>hint logic? I feel this is really the modeler's responsibility and gives a
>nice, centralized way to improve fault behaviour especially when
>optimizing/tuning.
Agreed. I've been thinking about this before. Again, this was postponed due
to the lack of time.
>- I miss some delegates; OperationObserver does some things, but pluggable
>observers for 'events' like with EOF are IMHO essential. I think
>notifications are a double-edged sword because of the inherent problem of
>ordered message delivery. Any thoughts, ideas on this?
I totally agree. Originally we did not implement any notifications,
delegates and such, because the flow of events in the access layer was
changing all the time. Now the overall flow seems to be rather stable, and
it is the right time to start designing such things. I am not ready to
suggest anything at the moment, but we need to start this work.
>- how can I help?
I will send a separate email on that.
Andrus
This archive was generated by hypermail 2.0.0 : Mon Sep 02 2002 - 12:45:54 EDT