You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Gennady Azarenkov <ga...@gmail.com> on 2005/12/01 07:54:57 UTC
Re: TCK: multivalue
>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 :)
>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 :)
thanks,
Gena
Gennady Azarenkov
eXo platform
----- Original Message -----
From: "Stefan Guggisberg" <st...@gmail.com>
To: <ja...@incubator.apache.org>; "Gennady Azarenkov"
<ge...@exoplatform.com>
Sent: Wednesday, November 30, 2005 7:04 PM
Subject: Re: TCK: multivalue
On 11/30/05, Gennady Azarenkov <ga...@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" <st...@gmail.com>
> To: <ja...@incubator.apache.org>; "Gennady Azarenkov"
> <ge...@exoplatform.com>
> Sent: Wednesday, November 30, 2005 4:08 PM
> Subject: Re: TCK: multivalue
>
>
> On 11/30/05, Gennady Azarenkov <ga...@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
> >
> >
>
>
Re: TCK: multivalue
Posted by Peeter Piegaze <pe...@day.com>.
Hi Gennady,
You wrote:
> 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 :)
As Stefan points out, the spec is quite clear on this issue. The
PropertyDefinition is "sticky". It is determined once on property
creation and that's it. Therefore the TCK test is correct. See the
Javadoc box for Property.getDefinition in section 6.7.18 of the spec:
<quote>
PropertyDefinition Property.getDefinition()
Returns the property definition that applies to this Property. In some
cases there may appear to be more than one definition that could apply
to this property. 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. How this governing definition is
selected upon property creation from among others which may have been
applicable is an implementation issue and is not covered by this
specification.
Throws a RepositoryException if an error occurs.
</quote>
Notice that from an implementation point of view this is a simplifying
restriction in that you are not permitted to dynamically re-associate
properties with property definitions after creation. Presumably this
makes your job easier, not harder, right?
Cheers,
Peeter
Re: TCK: multivalue
Posted by Gennady Azarenkov <ga...@gmail.com>.
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" <st...@gmail.com>
To: <ja...@incubator.apache.org>; "Gennady Azarenkov"
<ge...@exoplatform.com>
Sent: Thursday, December 01, 2005 11:57 AM
Subject: Re: TCK: multivalue
On 12/1/05, Gennady Azarenkov <ga...@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" <st...@gmail.com>
> To: <ja...@incubator.apache.org>; "Gennady Azarenkov"
> <ge...@exoplatform.com>
> Sent: Wednesday, November 30, 2005 7:04 PM
> Subject: Re: TCK: multivalue
>
>
> On 11/30/05, Gennady Azarenkov <ga...@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" <st...@gmail.com>
> > To: <ja...@incubator.apache.org>; "Gennady Azarenkov"
> > <ge...@exoplatform.com>
> > Sent: Wednesday, November 30, 2005 4:08 PM
> > Subject: Re: TCK: multivalue
> >
> >
> > On 11/30/05, Gennady Azarenkov <ga...@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
> > >
> > >
> >
> >
>
>
Re: TCK: multivalue
Posted by Stefan Guggisberg <st...@gmail.com>.
On 12/1/05, Gennady Azarenkov <ga...@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" <st...@gmail.com>
> To: <ja...@incubator.apache.org>; "Gennady Azarenkov"
> <ge...@exoplatform.com>
> Sent: Wednesday, November 30, 2005 7:04 PM
> Subject: Re: TCK: multivalue
>
>
> On 11/30/05, Gennady Azarenkov <ga...@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" <st...@gmail.com>
> > To: <ja...@incubator.apache.org>; "Gennady Azarenkov"
> > <ge...@exoplatform.com>
> > Sent: Wednesday, November 30, 2005 4:08 PM
> > Subject: Re: TCK: multivalue
> >
> >
> > On 11/30/05, Gennady Azarenkov <ga...@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
> > >
> > >
> >
> >
>
>