Craig,
I've been silent on that, since I really don't know a good answer. I would
really like to get rid of a name string and replace it with an object. I
just don't know if there is a better way to do it.
Replacing with ObjEntity will make DataObjects tied to the DataMap that
seems unneeded (plus the serialization issues that you mentioned). Using
Class leaves us with the entity resolution issues.
What I am wondering though, is if we use Class, do we still need a method
"getObjEntityName" with all the new EntityResolver stuff? Can it be so that
this method becomes unused and can be just taken out (or deprectated and
returning some dummy string)?
Andrus
>
>
>
> ----------Forwarded message ----------
>
> Hi,
> While doing the recently committed changes to queries (deprecating
> get/setObjEntityName), I realised the ObjectId also still uses
> ObjEntityName. For that reason alone, we have to maintain support in
> Query for the root being the name of the Entity.
>
> Is it a good idea to modify ObjectId to store the ObjEntity instead of
> it's name? At the moment ObjectId is quite lightweight... would this
> weigh it down too much (hmmm, serialiaation might be an issue). Maybe
> we could store the Class instead of the ObjEntity?
>
> ObjEntity is better in that we can then maintain getObjEntityName to
> return the obvious. If we went with the Class, then there'd by no easy
> way to retain that method's functionality and we might have to remove
> it.
>
> Of course, there may be other overriding issues I'm not aware of. Any
> thoughts/comments?
>
> Craig
>
This archive was generated by hypermail 2.0.0 : Thu Nov 14 2002 - 17:23:05 EST