On 12/1/05, Gennady Azarenkov <[EMAIL PROTECTED]> wrote: > >no;) the reason for grouping those methods in a separate interface > >(PropertyDefinition in this case) was that we tried to avoid > >cluttering the already 'heavy' Node and Property interfaces even more. > > >the definition of an Item is determined upon its creation and doesn't > >change afterwards. > > yes, upon creation of a property (meaning set*not existed*Property) it uses > a single particular definition (that is single-value of course) > but if there is one value and double definition we can not determine for > sure > its multiplicity for just retrieved from storage *existed* value > (getProperty/getValue) > unless some "multiplicity flag" is stored along with Property right ? > so in this case it is property of Property rather than property of > PropertyDefinition :)
i don' agree, sorry. the spec clearly mandates that an Item 'knows' its definition, i.e. the definition that was used and assigned upon Item creation. the definition states whether the Property is muli-valued or not. in jackrabbit, every Item keeps a reference to its definition. > > >see 6.7.18 in the spec: > > ><quote> > >... > >PropertyDefinition getDefinition() > >... > >However, it is assumed that upon creation of this property, a single > >particular definition was used and it is that definition that this > >method returns. > >... > ></quote> > > >therefore, in the above example, prop1 *is* single-valued and cannot > >be set with a valuer array. > > sorry, i just cant find clear definition in the specs and want to know this > matter > for sure as i experienced some difficulties in implementation and testing :) take a look at jackrabbit if you need ideas who to implement the jsr 170 specification ;) wrt to the spec: the spec is imo pretty clear on that matter. see 6.7.18 cheers stefan > > > thanks, > Gena > > Gennady Azarenkov > > eXo platform > > ----- Original Message ----- > From: "Stefan Guggisberg" <[EMAIL PROTECTED]> > To: <[email protected]>; "Gennady Azarenkov" > <[EMAIL PROTECTED]> > Sent: Wednesday, November 30, 2005 7:04 PM > Subject: Re: TCK: multivalue > > > On 11/30/05, Gennady Azarenkov <[EMAIL PROTECTED]> wrote: > > thanks, Stefan > > > > >since prop1 *exists* and it is defined as being single-valued, as > > >reported by prop1.getDefinition().isMultiple() == false, setting it > > >to a value array *must* throw a ValueFormatException in order to > > >be compliant with the spec. > > > > well, according to > > >> "Whether a particular property is a multi-valued property is governed > > >> by > > >> the > > >> property definition applicable to it, which is determined by the node > > >> type of the > > >> property's parent node." > > prop1.getDefinition().isMultiple() can return either false or true > > (both are applicable for an *abstract* property based on > > PropertyDefinition > > only) > > unless multiplicity flag is stored with property, but in this case > > it seems logical to have Property.isMultiple(), no? > > no;) the reason for grouping those methods in a separate interface > (PropertyDefinition in this case) was that we tried to avoid > cluttering the already 'heavy' Node and Property interfaces even more. > > the definition of an Item is determined upon its creation and doesn't > change afterwards. > > see 6.7.18 in the spec: > > <quote> > ... > PropertyDefinition getDefinition() > ... > However, it is assumed that upon creation of this property, a single > particular definition was used and it is that definition that this > method returns. > ... > </quote> > > therefore, in the above example, prop1 *is* single-valued and cannot > be set with a valuer array. > > cheers > stefan > > > > > regards, > > Gena > > > > Gennady Azarenkov > > > > eXo platform > > > > ----- Original Message ----- > > From: "Stefan Guggisberg" <[EMAIL PROTECTED]> > > To: <[email protected]>; "Gennady Azarenkov" > > <[EMAIL PROTECTED]> > > Sent: Wednesday, November 30, 2005 4:08 PM > > Subject: Re: TCK: multivalue > > > > > > On 11/30/05, Gennady Azarenkov <[EMAIL PROTECTED]> wrote: > > > hi, > > > > > > are the SetValueString.testMultiValue() and > > > TestSetValueStringTest.testMultiString() tests correct > > > for a case if parent can have both multi- and single- valued property > > > (as > > > it > > > is in TCK)? > > > > > > having nt:unstructured /testroot/node1 node with single valued child > > > prop1="JCR" > > > then trying to set Value[] to this property and expecting > > > ValueFormatException > > > > > > but nt:unctructured can have either single- or multi- valued (residual) > > > child prop > > > and (4.7.1): > > > "Whether a particular property is a multi-valued property is governed by > > > the > > > property > > > definition applicable to it, which is determined by the node type of the > > > property's parent node." > > > > since prop1 *exists* and it is defined as being single-valued, as > > reported by prop1.getDefinition().isMultiple() == false, setting it > > to a value array *must* throw a ValueFormatException in order to > > be compliant with the spec. > > > > cheers > > stefan > > > > > > > > independently on current value. Correct? > > > > > > regards, > > > Gena > > > > > > Gennady Azarenkov > > > > > > eXo platform > > > > > > > > > > > >
