Done. WRT equals and hashCode, I used the name of the class for both,
under the assumption that we want ObjectId's to be equal/hash correctly
even if the Class'es are loaded from different ClassLoaders.
Certainly the unit tests passed with flying colours, so I'm sure it
works in the normal case.. do you think that that is a valid assumption
for all cases?
Craig
On Fri, 2002-11-15 at 11:47, Andrus Adamchik wrote:
> Cool, so we have a solution. One thing we need to test is how "equals" and
> "hashCode" works with these changes - this is at the core of being able to
> use ObjectId as a key in hashes. I think I have an extensive test suite
> though.
>
> As for deprecation, so far I haven't been very consistent with that. But the
> main idea was to use deprecation for the API that has a strong chance of
> being used by Cayenne applications. So in this case I'd say forget
> deprecation and just get rid of "objEntityName" to simplify maintenance. We
> will put this in the release notes.
>
> Andrus
>
>
>
> Craig Miskell writes:
>
> > 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 - 21:30:24 EST