db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg von Frantzius <joerg.von.frantz...@artnology.com>
Subject Re: Minutes: JDO TCK Conference Call Friday, July 14 9 am PST
Date Mon, 17 Jul 2006 17:27:55 GMT
Craig L Russell schrieb:
>> If that's the case, then I wonder why a user would want to have FK 
>> constraints in his schema at all? They wouldn't be of much use then.
> If only using JDO, I agree. What matters is the consistency of the 
> object model, which is managed by the JDO implementation without help 
> from the database. But seldom is JDO the only access path to the database.
To me this means losing an important data security feature when using 
JDO over other access paths to the DB. FK constraints can prevent you 
from inadvertently deleting data, and by silently removing any dangling 
references on the object level (and so circumventing any FK constraints) 
you are entirely losing this kind of "safety belt"! JDO would never tell 
you about these dangling references, but instead would silently go and 
delete that information.

As I wrote in an earlier mail, we had a case here where we were really 
lucky that the FK constraint would fire upon deletion, because we didn't 
think of all the relationships that an object would be removed from, and 
for which we really didn't want to lose the information. That was for 
users that are logged as creators and modifiers of other objects: if you 
can delete a user, you'll lose the information about who created or 
edited an object, something that would have gone lost silently forever 
if it wasn't for the FK constraints firing.
>> I may also add that, as far as I know, JPOX nulls out only for 
>> one-one bidirectional, not for one-many, so there would be some 
>> inconsistency of behaviour here.
> Interesting point, but without another level of detail, it's hard to 
> evaluate this statement.
If you look at the code in DeleteRequest, you'll see that in execute() 
it'll null out FKs for any fields obained using 
getFildsWithRelatedObjects(). The latter's javadoc says

         * All fields that have related objects and where we use the 
related object to
         * maintain a relationship. These are used where we have 1-1 
         * relationships with a single FK (in the other object).
         * @return The fields with related objects
        public FieldMetaData[] getFieldsWithRelatedObjects()

That's the case for 1-1 relationships with "mapped-by" on the side where 
the object is deleted. From what I saw in my tests, that's where the 
nulling out happens, and it doesn't happen for one-many relationships 
with "mapped-by", so you'll see FK constraints violations there.
> Regards,
> Craig
>> Regards,
>> Jörg
>> Craig L Russell schrieb:
>>> 2. Deletion of objects when foreign-key is present (JDO-392) (any 
>>> and all) It seems that there are two different issues: managing the 
>>> memory model and managing the database. Craig opines that the 
>>> general case of consistency is already covered in the chapter on 
>>> mapping, requiring that the object model be consistent after a 
>>> flush. Object model consistency would disallow a reference to a 
>>> deleted object, so the natural behavior would be to nullify the 
>>> reference to the deleted object. For to-many relationships mapped to 
>>> a foreign key on the other side, the consistency rule would delete 
>>> the reference from the collection on the one- side of the 
>>> relationship. So it seems that the JPOX behavior as originally 
>>> reported is consistent and we might simply document it in the 
>>> specification.
>> Why does object model consistency disallow a reference to a deleted 
>> object?
>> <joerg.von.frantzius.vcf>
> 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!

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