I just checked and the only places that use getObjEntityName within
cayenne are those that are using it to
a) lookup an entity by name (using entity resolver)
b) Using it as the root of a query
c) For error messages
The first case is trivial to change, and the second requires no code
change whatsoever. In the third, the class name is sufficient to
identify the relevant ObjEntity anyway, so no problem there either.
And I was just wondering about the dummy value... there's no need to
return one. All the code that currently constructs ObjectId's obviously
has access to the ObjEntity name. We just have to change the
constructors of ObjectId to take a Class, keep the setObjEntityName
method (deprecated of course) and manually call it after constructing an
ObjectId. When the get/set methods eventually goes away, so does the
calls to set. All external code still works perfectly (although who'd
be relying on objentityName from an objectid I don't know ;-))
What do you think?
Craig
On Fri, 2002-11-15 at 11:22, Andrus Adamchik wrote:
> 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:39:33 EST