jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gennady Azarenkov <gazaren...@gmail.com>
Subject Re: TCK: multivalue
Date Thu, 01 Dec 2005 13:56:57 GMT
hi Stefan and Peeter,

thanks for your time :)

so have to store multivalue status along with Property

regards,
Gena

Gennady Azarenkov

eXo platform

----- Original Message ----- 
From: "Stefan Guggisberg" <stefan.guggisberg@gmail.com>
To: <jackrabbit-dev@incubator.apache.org>; "Gennady Azarenkov" 
<gennady.azarenkov@exoplatform.com>
Sent: Thursday, December 01, 2005 11:57 AM
Subject: Re: TCK: multivalue


On 12/1/05, Gennady Azarenkov <gazarenkov@gmail.com> 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" <stefan.guggisberg@gmail.com>
> To: <jackrabbit-dev@incubator.apache.org>; "Gennady Azarenkov"
> <gennady.azarenkov@exoplatform.com>
> Sent: Wednesday, November 30, 2005 7:04 PM
> Subject: Re: TCK: multivalue
>
>
> On 11/30/05, Gennady Azarenkov <gazarenkov@gmail.com> 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" <stefan.guggisberg@gmail.com>
> > To: <jackrabbit-dev@incubator.apache.org>; "Gennady Azarenkov"
> > <gennady.azarenkov@exoplatform.com>
> > Sent: Wednesday, November 30, 2005 4:08 PM
> > Subject: Re: TCK: multivalue
> >
> >
> > On 11/30/05, Gennady Azarenkov <gazarenkov@gmail.com> 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
> > >
> > >
> >
> >
>
> 


Mime
View raw message