On Wed, Jul 14, 2010 at 12:29 PM, Craig L Russell <craig.russ...@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.
