db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthew Adams <matt...@matthewadams.me>
Subject Re: Fetch configuration
Date Thu, 15 Jul 2010 17:48:52 GMT
On Wed, Jul 14, 2010 at 12:29 PM, Craig L Russell
<craig.russell@oracle.com>wrote:

>
> On Jul 14, 2010, at 7:53 AM, Matthew Adams wrote:
>
> Seems like a good idea.  Could foreign keys be considered the same as basic
>> fields for the purposes of the default fetch group?  That is, fetched by
>> default unless the user says don't fetch?
>>
>
> That's where I would start. We need to decide whether this is just a
> relational database issue and use mapping metadata or if it's a general
> datastore issue and use jdo metadata. In other words, we could put columns
> into the fetch group or define a new jdo metadata concept to describe "the
> many-to-one artifacts that aren't visible as fields but are required to
> instantiate relationships".

Understood.


>
>> I assume that if an object is loaded using a fetch group that doesn't
>> include foreign keys and the foreign key field is dereferenced, the impl
>> would go back to the datastore and load the referenced object's foreign
>> key
>> via the referencing object's key (simple lazy loading).
>>
>
> Actually, what I expect the implementation to do is to load the referenced
> object directly using a join of the primary table (where t0.pk = ?) with
> the referenced table (and t0.fk = t1.pk). One round trip to the datastore
> instead of two.
>
That's actually what I had in mind; I would also expect an impl to do it in
one trip.


>
> But a compliant implementation can eagerly load the foreign keys today,
> since there's nothing in the spec to prohibit it.
>
> I think this would be a good feature to discuss via JIRA. There are
> specification issues as well as technical issues to work through.
>
>
> What's the
>> behavior of a JDO impl that supports change of identity if I load an
>> object
>> that uses application identity with a fetch group that doesn't include
>> foreign keys of direct relationships, I then change the identity value of
>> the referencing object, and then I dereference a direct relationship that
>> was not loaded?  The impl would not have a way to get back to the
>> datastore
>> to get the referenced object because the referencing object's key has been
>> changed.
>>
>
> I'd expect that the behavior would depend on whether the change of pk was
> flushed or not. If not flushed, the original pk is still visible in the
> datastore. If flushed, the changed pk is visible (along with all the
> consequent fk's that refer to the changed pk).
>
>
> It seems to me that a dumb implementation should throw
>> JDOUserException; a smart impl could cache the original value of the
>> referencing object's key if changed during the transaction and use the
>> cached id value to go get the referenced foreign key & object.  I could
>> see
>> this as being a JDO option:
>> javax.jdo.option.LazilyLoadDirectRelationshipWithoutLoadedForeignKey.
>>
>
> I think that an impl that supports change of pk should also be able to
> handle this case without being explicit about it.
>
> Sounds reasonable to me.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message