jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peeter Piegaze" <peeter.pieg...@day.com>
Subject Re: Conflicting propertyDefinitions within a nodeType
Date Thu, 04 May 2006 10:01:13 GMT
Hi David,

Actually, the proposed maintenance release (JCR 1.0.1) is publicly
available, so you can have a look at it:

http://jcp.org/aboutJava/communityprocess/maintenance/jsr170/index.html

The revised section that addresses your concerns is 6.7.8 (pp. 135-6).
There is a diff version included so you can see the changes from 1.0
highlighted.

I should point out that this is not a final release, so theoretically
it could change. But frankly that is pretty unlikely...unless, of
course, you yourself identify a problem :-)

Cheers, hope this helps,
Peeter

On 5/4/06, Stefan Guggisberg <stefan.guggisberg@gmail.com> wrote:
> On 5/3/06, David Kennedy <davek@us.ibm.com> wrote:
> > I have 2 nodeType definitions where one inherits from the other.  Both
> > have a definition for a property having the same name.  In this particular
> > case they happened to be the same (have the same attribute values).  On
> > registration of the nodeType, I get a NodeTypeConflictException:
> > "ambiguous property definition". Since the inheritance model of nodeType
> > definition is left up to the implementation, what is jackrabbit's model?
> > Why wouldn't the subtype definition override the supertype's definition?
>
> the short answer is: in order to stay out of trouble ;-)


>
> as you mentioned the node type inheritance behavior is not clearly defined.
>
> let's take types T1 and T2.
>
> T1 has a non-mandatory string-valued property, P.
> T2 has a mandatory string-valued property, P.
>
> T2 could theoretically be a subclass of T1. T1 on the other hand
> cannot be a subclass of T2 because the 'mandatory' constraint
> of T2 would be violated.
>
> the issue of overriding property or child node definitions in
> node type subclasses is not just limited to the 'mandatory' flag.
>
> e.g. the 'protected' flag, required type, value constraints etc.
> pose similar problems.
>
> take for example a property definition with a value constraint
> being overridden in a subclass by a property definition with
> a different value constraint. if we would allow definitions to be
> overridden by more restrictive definitions in subclasses, how do
> we determine if a specific value constraint is more restrictive than
> another? this could be very difficult, especially in the case of
> regular expressions...
>
> another example: T1 defines a multi-valued property P. T2 extends
> from T1 and defines a single-valued but otherwise identical property.
> is T2's definition of P overriding T1's definition or is it just
> adding another definition? nt:unstructured for that matter contains
> two property definitions that are identical except for their 'multiple'
> flag.
>
> the current implementation in jackrabbit is absolutely compliant
> with the jsr-170 spec. i agree that node type inheritance behavior needs to be
> clarified; we've already discussed this issue earlier in the jsr-170
> expert group.
> the good news is that the next maintenance release (jcr 1.0.1) will
> address this
> issue.


>
> cheers
> stefan
>
> >
> > FWIW, this is where it is failing in EffectiveNodeType:
> >
> >                                 if (pd.getRequiredType() ==
> > epd.getRequiredType()
> >                                         && pd.isMultiple() ==
> > epd.isMultiple()) {
> >                                     // conflict
> >                                     String msg = "The property definition
> > for '"
> >                                             + name + "' in node type '"
> >                                             + def.getDeclaringNodeType()
> >                                             + "' conflicts with node type
> > '"
> >                                             +
> > existingDef.getDeclaringNodeType()
> >                                             + "': ambiguous property
> > definition";
> >
> > David
> >
>

Mime
View raw message