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: Spec review items Chapter 18
Date Mon, 20 Feb 2006 19:27:13 GMT
Hi Craig,

I agree, thanks for the clarification!

Regards Michael

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


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