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 Wed, 16 Feb 2005 18:20:11 GMT
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
> are
> >> fetched.
> >>
> >> The JDO PersistenceManager:
> >> A12.6.1-2 [loads persistent values from the
> >> datastore into the
> >> instance;]
> >> A12.6.1-3 [for hollow instances, changes the
> state
> >> to persistent-clean
> >> in a datastore transaction;] or A12.6.1-4
> >> [persistent-nontransactional
> >> in an optimistic transaction,] and A12.6.1-5 [if
> the
> >> class of the
> >> instance implements LoadCallbacks calls
> >> jdoPostLoad.]
> >> </spec 12.6.1>
> >>
> >> Craig
> >>
> >> On Feb 7, 2005, at 2:12 PM, Craig Russell wrote:
> >>
> >>> I hear you (all). I'll propose spec changes as
> >> soon as I can get to
> >>> it. Probably before the reconsideration version.
> >>>
> >>> Craig
> >>>
> >>> On Feb 6, 2005, at 11:39 PM, Wes Biggs wrote:
> >>>
> >>>> +1 for changing the semantics of "default fetch
> >> group" to "current
> >>>> fetch group"
> >>>> +1 for adding boolean signatures to retrieve().
> >>>> +1 to Abe starting a separate thread on how
> fetch
> >> groups apply to
> >>>> detach operations, because even though I
> disagree
> >> at first blush that
> >>>> detach shouldn't *always* apply the current
> fetch
> >> group, you're
> >>>> pretty good at convincing me I'm wrong.
> >>>>
> >>>> erik@jpox.org wrote:
> >>>>
> >>>>> +1 to add
> >>>>>
> >>>>>> new methods that, like retrieve(), take a
> >> boolean argument for
> >>>>>> whether
> >>>>>> to apply the fetch plan.
> >>>>>>
> >>>>>
> >>>>>
> >>>>> Quoting Abe White <awhite@solarmetric.com>:
> >>>>>
> >>>>>
> >>>>>>> +1 to change onlyDFG to onlyCFG in retrive
> >> methods.
> >>>>>>>
> >>>>>>> What about refresh methods? I still see
> >> backward compability
> >>>>>>> issues if
> >>>>>>> refresh
> >>>>>>> methods use current fetch plan rather than
> >> loaded fields.
> >>>>>>>
> >>>>>> +1 from me too.  But we also need a
> >> PM.retrieve(Object, boolean).
> >>>>>> Right now the boolean arg form only exists
> with
> >> retrieveAll().
> >>>>>>
> 
=== message truncated ===


		
__________________________________ 
Do you Yahoo!? 
Meet the all-new My Yahoo! - Try it today! 
http://my.yahoo.com 
 


Mime
View raw message