db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff hendrey <geoff_hend...@yahoo.com>
Subject RE: Surrogate keys and application identity
Date Thu, 17 Feb 2005 16:00:39 GMT
So far Wes, Eric, Bin, and I seem to support the idea
of renaming the "primary-key" attribute of .jdo
metadata to "identity". I really think we should do
this, and change all references in the documentation
to refer to "identity field(s)" rather than "primary
key fields".

-geoff




--- Eric Samson <eric@xcalia.com> wrote:

> Geoff
> 
> I agree that would be better.
> 
> If we are going in that direction, I would also like
> to rename "Datastore
> Identity" to something that better represents what
> it is: "Transparent
> Identity".
> 
> Then "Application Identity" could become "Explicit
> Identity", with sub-types
> like "Application Identity" (really managed by the
> application that is
> responsible to supply identity values), "Datastore
> Identity" (relying on a
> specific datastore features for identity, like
> sequences or auto-incrmented
> columns)...
> 
> But I don't know if we can really change all these
> things now, with all the
> JDO users we have.
> 
> Best Regards
> .:
> Eric Samson, xcalia
> 
> -----Message d'origine-----
> De : geoff_hendrey@yahoo.com
> [mailto:geoff_hendrey@yahoo.com] 
> Envoyé : mercredi 16 février 2005 19:20
> À : Craig Russell
> Cc : JDO Expert Group; jdo-dev@db.apache.org
> Objet : Re: Surrogate keys and application identity
> 
> Personally I think we *should* change the spec.  The
> use of "primary key" to
> describe fields in a Java Object model was a poor
> choice. I have grepped the
> doc too for "primary key", and as you pointed out,
> it occurs in a handful of
> places. Certainly small enough to edit in 15 minutes
> or so. I'll happily do
> it myself  and send you redlines if you like. 
> 
> I think all places in the document where it says
> "primary key field" (or the
> like) should be changed to "identity field".
> Furthermore, I think the .jdo
> metadata should change the "primary-key" attribute
> to "identity".  It just
> doesn't make sense to introduce the notion of
> primary key into a spec that
> is supposed to be independent of the datastore.
> 
> This would completely disambiguate "primary key".
> And we would be free to
> use the term "primary key" in the ORM to describe
> ... a PRIMARY KEY
> (shockingly). I
> mean,   doesn't it seem silly that we are hamstrung
> from being able to say <primary-key> in an XML
> format for ORM??
> 
> -geoff
> 
> 
> 
> --- Craig Russell <Craig.Russell@Sun.COM> wrote:
> 
> > Hi Geoff,
> > 
> > On Feb 12, 2005, at 8:22 PM, Geoff hendrey wrote:
> > 
> > > I think we've reached agreement on another issue
> > as
> > > well. That is, changing <datastore-identity> to
> <primary-key>.
> > 
> > I'm not sold on this yet.
> > 
> > We have defined the concept of primary key in the
> object model and 
> > enhancer. "Application identity is often called
> primary key"; "An 
> > application attempt to change the identity of an
> instance (by writing 
> > a primary key field)"; "Application developers
> should take into 
> > account that changing primary key values changes
> the identity of the 
> > instance in the datastore"; "A JDO implementation
> is required to 
> > support either or both of application (primary
> key) identity or 
> > datastore identity"; "the names of the non-static
> fields in the 
> > ObjectId class must include the names of the
> primary key fields in the 
> > JDO class"; "the equals() and hashCode() methods
> of the ObjectId class 
> > must use the value(s) of all the fields
> corresponding to the primary 
> > key fields in the JDO class"; "A primary key
> identity is associated 
> > with a specific set of fields"; "[a hollow
> instance] transitions to 
> > persistent-clean if a read access is made to any
> persistent field 
> > other than one of the primary key fields"; "The
> "none" fetch group 
> > contains only primary key fields".
> > 
> > You get the point, which is that I don't want to
> go through the spec 
> > and adapt all references that currently refer to
> primary key and 
> > change them to something else.
> > 
> > How about a different approach?
> > 
> > You could use the <datastore-identity> element in
> a class that is 
> > defined to use application identity. This would
> not be required, but 
> > would be permitted. Your implementation would
> define the surrogate key 
> > using the <datastore-identity> definition, instead
> of defining the 
> > primary key columns using the application identity
> key fields.
> > 
> > Craig
> > 
> > >
> > > -geoff
> > >
> > > --- Craig Russell <Craig.Russell@Sun.COM> wrote:
> > >
> > >> Javadogs,
> > >>
> > >> I think I've captured this proposal in the
> > attached
> > >> specification
> > >> update.
> > >>
> > >> I plan to include this in the reconsideration
> > Public
> > >> Draft.
> > >>
> > >> <spec 12.6.1>
> > >> void retrieve(Object pc);
> > >> void retrieve(Object pc, boolean FGOnly); void 
> > >> retrieveAll(Collection pcs); void
> retrieveAll(Collection pcs, 
> > >> boolean FGOnly); void retrieveAll(Object[]
> pcs); void 
> > >> retrieveAll(Object[] pcs, boolean FGOnly);
> These methods request 
> > >> the PersistenceManager to
> > load
> > >> all persistent
> > >> fields into the parameter instances. Subsequent
> > to
> > >> this call, the
> > >> application might call makeTransient on the
> parameter instances, 
> > >> and the fields can no longer be touched by the
> PersistenceManager. 
> > >> The PersistenceManager might also retrieve
> related instances 
> > >> according to the current fetch plan or a
> vendor-specific
> > pre-read
> > >> policy (not
> > >> specified by JDO).
> > >>
> > >> If the FGOnly parameter is true, and the fetch
> > plan
> > >> has not been
> > >> modified from its default setting (see 12.7.1),
> > then
> > >> this is a hint to
> > >> the implementation that only the fields in the
> current fetch group 
> > >> need to be retrieved. A compliant
> implementation is permitted to 
> > >> retrieve all fields regardless of the setting
> of this parameter. 
> > >> After the call with the FGOnly parameter true,
> all fields in the 
> > >> current fetch group must have been fetched, but
> other fields might 
> > >> be fetched lazily by the implementation.
> > >>
> > >> If the FGOnly parameter is true, and the fetch
> > plan
> > >> has been changed,
> > >> then only the fields specified by the fetch
> plan
> 
=== message truncated ===



		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Helps protect you from nasty viruses. 
http://promotions.yahoo.com/new_mail

Mime
View raw message