db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Bouschen <mbo.t...@spree.de>
Subject Re: jdo.dtd changes
Date Mon, 20 Feb 2006 19:21:35 GMT
Hi Craig,

I have updated jdo.dtd as you proposed and then changed jdo.xsd, orm.dtd 
and orm.xsd accordingly. I figured out that jdo.dtd and orm.dtd define 
the subelements for the element key in a different order. I fixed this 
and change orm.dtdt to match the order as defined in jdo.dtd.

Please have a look at the attached patch. It includes the changes of 
jdo.dtd, jdo.xsd, orm.dtd and orm.xsd. I would like to check them in 
first, before checking in the schema validation test for api20.

Regards Michael

> Hi Michael,
>
> On Feb 19, 2006, at 12:31 PM, Michael Bouschen wrote:
>
>> Hi Craig,
>>
>> I implemented the jdo.dtd changes, you find a patch file attached.
>>
>> However, I have three questions:
>> (1) I changed the foreign-key elements as I described below:
>>  <!ELEMENT foreign-key (extension*, column*, field*, property*,  
>> extension*)>
>
>
> I think this should allow any number of extensions before or after,  
> and your choice of one of column*, field*, or property*. I don't  
> think it makes sense for a foreign key, index, or unique to combine  
> more than one.
>
> I thought that (column* | field* | property*) said that.
>
> So, my proposal:
>
> <!ELEMENT foreign-key (extension*, (column*| field*| property*),  
> extension*)>
>
>
>> I did the same change for the elements index, unique and fetch-group.
>> This change might not what you had in mind. Please let me know.
>> (2) I changed the value order for the foreign-key attributes delete- 
>> action and update-action to match the definition of delete-action  
>> and update-action in other elements. The only difference is that  
>> foreign-key does not allow the value 'none'...
>
>
> I found some information on this:
> InnoDB rejects any INSERT or UPDATE operation that attempts to create  
> a foreign key value in a child table if there is no a matching  
> candidate key value in the parent table. The action InnoDB takes for  
> any UPDATE or DELETE operation that attempts to update or delete a  
> candidate key value in the parent table that has some matching rows  
> in the child table is dependent on the referential action specified  
> using ON UPDATE and ON DELETE subclauses of the FOREIGN KEY clause.  
> When the user attempts to delete or update a row from a parent table,  
> and there are one or more matching rows in the child table, InnoDB  
> supports five options regarding the action to be taken:
>
> CASCADE: Delete or update the row from the parent table and  
> automatically delete or update the matching rows in the child table.  
> Both ON DELETE CASCADE and ON UPDATE CASCADE are supported. Between  
> two tables, you should not define several ON UPDATE CASCADE clauses  
> that act on the same column in the parent table or in the child table.
> SET NULL: Delete or update the row from the parent table and set the  
> foreign key column or columns in the child table to NULL. This is  
> valid only if the foreign key columns do not have the NOT NULL  
> qualifier specified. Both ON DELETE SET NULL and ON UPDATE SET NULL  
> clauses are supported.
> NO ACTION: In standard SQL, NO ACTION means no action in the sense  
> that an attempt to delete or update a primary key value is not  
> allowed to proceed if there is a related foreign key value in the  
> referenced table. InnoDB rejects the delete or update operation for  
> the parent table.
> RESTRICT: Rejects the delete or update operation for the parent  
> table. NO ACTION and RESTRICT are the same as omitting the ON DELETE  
> or ON UPDATE clause. (Some database systems have deferred checks, and  
> NO ACTION is a deferred check. In MySQL, foreign key constraints are  
> checked immediately, so NO ACTION and RESTRICT are the same.)
> SET DEFAULT: This action is recognized by the parser, but InnoDB  
> rejects table definitions containing ON DELETE SET DEFAULT or ON  
> UPDATE SET DEFAULT clauses.
>
> So I think that the delete-action should allow all of the cascade,  
> null, none, restrict, and default. None might be "deferred checking"  
> but otherwise is the same as restrict.
>
>> (3) I think the attribute update-action should restrict the  
>> permitted values to the same values as key/value update-action, so  
>> 'none' should be allowed. What do you think?
>
>
> I think both delete-action and update-action should allow all of the  
> actions.
>
>>
>> As soon as we agreed on the changes I can update the jdo.xsd  
>> accordingly and change the test cases Positive99-dtd.jdo and  
>> Positive99-xsd.jdo.
>
>
> Ok.
>
> Craig
>
>>
>> Regards Michael
>>
>>> Hi Craig,
>>>
>>> sorry for not replying earier.
>>>
>>>> Javadogs,
>>>>
>>>> I've made these changes to the final spec.
>>>>
>>>> Craig
>>>>
>>>> On Feb 15, 2006, at 11:37 AM, Craig L Russell wrote:
>>>>
>>>>> 1. <!ATTLIST column allows-null CDATA #IMPLIED>
>>>>> should be
>>>>> <!ATTLIST column allows-null (true|false) #IMPLIED>
>>>>>
>>>>> 2. <!ELEMENT foreign-key (extension*, (column|field|property)*,  
>>>>> extension*)>
>>>>> should be
>>>>> <!ELEMENT foreign-key (extension*, (column*|field*|property*),  
>>>>> extension*)>
>>>>
>>>>
>>>>
>>> I read (column*|field*|property*) as: either a list of columns or  a 
>>> list of fields or a list of properties. So you cannot have  fields 
>>> and properties mixed.  Did you intend to have a list of  columns, 
>>> followed by a list of fields, followed by a list of  properties:
>>>  <!ELEMENT foreign-key (extension*, column*, field*, property*,  
>>> extension*)>
>>>
>>> The fetch-group element looks similar. Did you paln you change  this 
>>> too:
>>>  <!ELEMENT fetch-group (extension*, (fetch-group|field|property)*,  
>>> extension*)>
>>>
>>> Regards Michael
>>>
>>>>>
>>>>> 3. same as 2 for index
>>>>
>>>>
>>>>
>>>>
>>>> Same as 2 for unique as well.
>>>>
>>>>>
>>>>> 4. <!ATTLIST element update-action CDATA #IMPLIED>
>>>>> element update-action should restrict the permitted values to  the 
>>>>> same values as foreign-key update-action
>>>>>
>>>>> 5. Missing element key attribute update-action
>>>>>
>>>>> 6. Missing element value attribute update-action
>>>>>
>>>>> 7. Element order should not have the delete-action, update- 
>>>>> action, indexed, and unique attributes
>>>>> Anything else?
>>>>>
>>>>> Craig
>>>>>
>>>>> 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!
>>>>
>>>>
[...]

-- 
Michael Bouschen		Tech@Spree Engineering GmbH
mailto:mbo.tech@spree.de	http://www.tech.spree.de/
Tel.:++49/30/235 520-33		Buelowstr. 66			
Fax.:++49/30/2175 2012		D-10783 Berlin			


Mime
View raw message