You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-dev@db.apache.org by Craig Russell <Cr...@Sun.COM> on 2005/02/16 18:25:53 UTC
Re: Surrogate keys and application identity
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 <Cr...@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 <aw...@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().
>>>>>>
>>>>>> For refresh, we could leave the JDO 1 refresh()
>> methods as-is and
>>>>>> add
>>>>>> new methods that, like retrieve(), take a
>> boolean argument for
>>>>>> whether
>>>>>> to apply the fetch plan.
>>>>>>
>>>>>> In fact, I've been arguing that we should do
>> the same for
>>>>>> detachCopy:
>>>>>> add a boolean argument on whether to apply the
>> current fetch plan
>>>>>> (and
>>>>>> if set to false the loaded field graph would
>> detach). But that's
>>>>>> another topic.
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>> Craig Russell
>>> Architect, Sun Java Enterprise System
>> http://java.sun.com/products/jdo
>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>> P.S. A good JDO? O, Gasp!
>>>
>> Craig Russell
>> Architect, Sun Java Enterprise System
>> http://java.sun.com/products/jdo
>> 408 276-5638 mailto:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
>>
>
>> ATTACHMENT part 2 application/pkcs7-signature
> name=smime.p7s
>
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail - Helps protect you from nasty viruses.
> http://promotions.yahoo.com/new_mail
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
RE: Surrogate keys and application identity
Posted by Eric Samson <er...@xcalia.com>.
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 <Cr...@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 <Cr...@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 <aw...@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
Re: Surrogate keys and application identity
Posted by Geoff hendrey <ge...@yahoo.com>.
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 <Cr...@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 <Cr...@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 <aw...@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