db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: Minutes: JDO TCK Conference Call Friday, July 14 9 am PST
Date Mon, 17 Jul 2006 17:51:05 GMT
Hi Jörg,

On Jul 17, 2006, at 10:27 AM, Jörg von Frantzius wrote:

> 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.

I'm not sure I understand your concern. Is it ok for the application  
to explicitly nullify references to instances that it deletes? It's  
not clear to me how a nullable database constraint improves the  
reliability of your user's code.

On the other hand, if it is a requirement of the object model that  
there must be a non-null reference to an instance, then would a not- 
null foreign key satisfy the requirement? In this case, JPOX's  
automatic nullification of the reference would cause a (null)  
constraint violation. Or JPOX would throw an exception if it knew  
about the not-null constraint. Or defer the delete until commit, by  
which time the other side would have to have been set to a valid not- 
deleted instance. And the application would have to be careful to set  
the other side of the relationship.

As you know, there are no TCK tests for these cases. I'd like to  
formalize the specification and add some tests once we all agree on  
the semantics.
>
> 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.

So is it the case that explicitly nullifying the relationship is  
illegal for the user? I'm trying to picture the security domain model  
where a user is authorized to delete from a table but is not  
authorized to set the column of a related table to null. How is this  
supposed to work?

>>> 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 bidirectional
>          * 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.

For one-many relationships there is no additional foreign key. Take  
the case of deleting an Employee for which there is a Department- 
Employee relationship. There is no explicit database action needed  
when deleting the Employee because there is no explicit reference  
from the DEPARTMENT table to the key values in the EMPLOYEE table.  
The primary key in EMPLOYEE defines the relationship.

Regards,

Craig

>>
>> 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!
>>
>
> <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!


Mime
View raw message