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: Spec review items Chapter 18
Date Mon, 20 Feb 2006 03:19:32 GMT
Hi Michael,

On Feb 19, 2006, at 10:27 AM, Michael Bouschen wrote:

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

Right. This defines a single foreign key constraint. I think it makes  
sense to have a constraint on a single reference, which means that a  
foreign key, index, or unique constraint should apply to a single set  
of columns, fields, or properties.

In most cases a constraint will have either a column* or a single  
field or a single property. But we wanted to allow for example a  
unique constraint on the combination of order id and line number,  
which are two different fields.

> 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*)>

No.
>
> The fetch-group element looks similar. Did you paln you change this  
> too:
>  <!ELEMENT fetch-group (extension*, (fetch-group|field|property)*,  
> extension*)>

No, this is very different. There is a heterogeneous collection of  
nested fetch groups, fields, and properties associated with a fetch  
group, so this should be some number of fetch-group plus some fields  
and some properties in whatever combination. So (fetch-group|field| 
property)* seems right. There is no reason to make the fetch groups  
first, the fields second, and the properties third. Any order would  
work.

Regards,

Craig

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

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