db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig Russell <Craig.Russ...@Sun.COM>
Subject Re: Surrogate keys and application identity
Date Wed, 16 Feb 2005 17:25:53 GMT
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().
>>>>>>
>>>>>> 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!

Mime
View raw message