You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Kaizer <Ka...@mastek.com> on 2007/09/21 14:20:38 UTC

Same name siblings with OCM

Hi,

I'm using OCM and wanted to know how Same name siblings work in this case.
For, example, if I dont want 2 objects under the same node with both having
a particular attribute with the same value, can this be achieved through
same name siblings? 

Thanks.
-- 
View this message in context: http://www.nabble.com/Same-name-siblings-with-OCM-tf4494352.html#a12817090
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.


Re: Same name siblings with OCM

Posted by Felix Meschberger <fm...@gmail.com>.
Am Montag, den 01.10.2007, 07:47 +0200 schrieb Bertrand Delacretaz:
> On 9/29/07, Felix Meschberger <fm...@gmail.com> wrote:
> 
> > ...As a side-node, IMHO (private and personal and not endorsed by anyone)
> > same-name-sibblings are a design error of the initial spec and should be
> > avoided...
> 
> Is there a config option in Jackrabbit that disables same name siblings?

Not that I would know of

> It might be useful to have that for people who adhere to your view
> (which is shared by many as I understand). But maybe that would be
> against the spec?

If I understand the spec correctly, the only way for a repository to
prevent SNS is to not have node types defined with same-name-sibblings.
As Jackrabbit supports the creation of new node types,
same-name-sibblings cannot be prevented on a repository-level.

So the only solution is to not use them at all and spread the word :-)

Regards
Felix


Re: Same name siblings with OCM

Posted by Bertrand Delacretaz <bd...@apache.org>.
On 9/29/07, Felix Meschberger <fm...@gmail.com> wrote:

> ...As a side-node, IMHO (private and personal and not endorsed by anyone)
> same-name-sibblings are a design error of the initial spec and should be
> avoided...

Is there a config option in Jackrabbit that disables same name siblings?

It might be useful to have that for people who adhere to your view
(which is shared by many as I understand). But maybe that would be
against the spec?

-Bertrand

Re: Same name siblings with OCM

Posted by Felix Meschberger <fm...@gmail.com>.
I fear you misunderstand the concept of same-name-sibblings. The concept
was introduced into the JCR standard to allow easy import of XML
documents, which allows for multiple child elements of the same parent
element to have the same name.

For example:
    <parent>
        <child attr="first" />
        <child attr="second" />
    </parent>

Without same name sibblings, the JCR node ".../parent" is only allowed
to have a single child node of the same name - "child" in this example.

As a side-node, IMHO (private and personal and not endorsed by anyone)
same-name-sibblings are a design error of the initial spec and should be
avoided.

Your use cases seems to be that you want to prevent that any two child
nodes of a parent node have a property whose name is the same, that is:
you want to prevent a situation with a property .../parent/child1/prop
and .../parent/child2/prop.

I have to say, as child1 and child2 are mostly independent of each
other, the repository has no means to prevent such a situation and OCM
does not have such a means, too. In fact, this is an application
requirement, which should be handled in a layer above the OCM (and JCR
by that matter).

If I am completely wrong, it would be great, if you could present a
sample to clarify your issue. Thanks.

Regards
Felix

Am Samstag, den 29.09.2007, 02:12 -0700 schrieb Kaizer:
> I guess what you mean is define a node type which says sameNameSiblings is
> false and specify that node type in my mapping.xml. But how would it check
> whether the two objects being stored under a node for that node type are
> same name siblings or not?Would it be based on some attribute of the object
> which i can specify through the mapping?
> Thanks.
> 
> 
> 
> 
> Christophe Lombart wrote:
> > 
> > On 9/21/07, Kaizer <Ka...@mastek.com> wrote:
> >>
> >>
> >> In my case, its not with a collection but my top level object itself
> >> would
> >> dictate based on one of its attributes whether another object of the same
> >> type can be stored under the same node.
> > 
> > For eg, I shouldnt be allowed to store 2 objects with the same "name"
> >> attribute under the same node.
> > 
> > 
> > Setting the sameNameSiblings = "false" in the childNodeDefinition is not a
> > solution ?
> > 
> > 
> > 
> > 
> > 
> > 
> > Christophe Lombart wrote:
> >> >
> >> > On 9/21/07, Kaizer <Ka...@mastek.com> wrote:
> >> >>
> >> >>
> >> >> Hi,
> >> >>
> >> >> I'm using OCM and wanted to know how Same name siblings work in this
> >> >> case.
> >> >
> >> >
> >> >
> >> > It works with collection converters. If you are using specific node
> >> types,
> >> > you have to use the NTCollectionConverterImpl otherwise you have to use
> >> > the
> >> > DefaultCollectionImpl. Both converters have almost the same behavior in
> >> > term
> >> > of subnode name definition. By default, they use the same name for all
> >> > subnodes. This is a predefined value like "collection-element". If the
> >> > class-descriptor matching to the collection elements has an id (see the
> >> > fieldescriptor definition), the id value is used to build the subnode
> >> > name.
> >> > There are some examples in the uni tests.
> >> >
> >> > If you have still some problems, you can send us more information about
> >> > your
> >> > content model and we will try to make the mapping together.
> >> >
> >> > br,
> >> > Christophe
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >> http://www.nabble.com/Same-name-siblings-with-OCM-tf4494352.html#a12821977
> >> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
> >>
> >>
> > 
> > 
> 


Re: Same name siblings with OCM

Posted by Kaizer <Ka...@mastek.com>.
I guess what you mean is define a node type which says sameNameSiblings is
false and specify that node type in my mapping.xml. But how would it check
whether the two objects being stored under a node for that node type are
same name siblings or not?Would it be based on some attribute of the object
which i can specify through the mapping?
Thanks.




Christophe Lombart wrote:
> 
> On 9/21/07, Kaizer <Ka...@mastek.com> wrote:
>>
>>
>> In my case, its not with a collection but my top level object itself
>> would
>> dictate based on one of its attributes whether another object of the same
>> type can be stored under the same node.
> 
> For eg, I shouldnt be allowed to store 2 objects with the same "name"
>> attribute under the same node.
> 
> 
> Setting the sameNameSiblings = "false" in the childNodeDefinition is not a
> solution ?
> 
> 
> 
> 
> 
> 
> Christophe Lombart wrote:
>> >
>> > On 9/21/07, Kaizer <Ka...@mastek.com> wrote:
>> >>
>> >>
>> >> Hi,
>> >>
>> >> I'm using OCM and wanted to know how Same name siblings work in this
>> >> case.
>> >
>> >
>> >
>> > It works with collection converters. If you are using specific node
>> types,
>> > you have to use the NTCollectionConverterImpl otherwise you have to use
>> > the
>> > DefaultCollectionImpl. Both converters have almost the same behavior in
>> > term
>> > of subnode name definition. By default, they use the same name for all
>> > subnodes. This is a predefined value like "collection-element". If the
>> > class-descriptor matching to the collection elements has an id (see the
>> > fieldescriptor definition), the id value is used to build the subnode
>> > name.
>> > There are some examples in the uni tests.
>> >
>> > If you have still some problems, you can send us more information about
>> > your
>> > content model and we will try to make the mapping together.
>> >
>> > br,
>> > Christophe
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Same-name-siblings-with-OCM-tf4494352.html#a12821977
>> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
>>
>>
> 
> 

-- 
View this message in context: http://www.nabble.com/Same-name-siblings-with-OCM-tf4494352.html#a12953571
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.


Re: Same name siblings with OCM

Posted by Christophe Lombart <ch...@gmail.com>.
On 9/21/07, Kaizer <Ka...@mastek.com> wrote:
>
>
> In my case, its not with a collection but my top level object itself would
> dictate based on one of its attributes whether another object of the same
> type can be stored under the same node.

For eg, I shouldnt be allowed to store 2 objects with the same "name"
> attribute under the same node.


Setting the sameNameSiblings = "false" in the childNodeDefinition is not a
solution ?






Christophe Lombart wrote:
> >
> > On 9/21/07, Kaizer <Ka...@mastek.com> wrote:
> >>
> >>
> >> Hi,
> >>
> >> I'm using OCM and wanted to know how Same name siblings work in this
> >> case.
> >
> >
> >
> > It works with collection converters. If you are using specific node
> types,
> > you have to use the NTCollectionConverterImpl otherwise you have to use
> > the
> > DefaultCollectionImpl. Both converters have almost the same behavior in
> > term
> > of subnode name definition. By default, they use the same name for all
> > subnodes. This is a predefined value like "collection-element". If the
> > class-descriptor matching to the collection elements has an id (see the
> > fieldescriptor definition), the id value is used to build the subnode
> > name.
> > There are some examples in the uni tests.
> >
> > If you have still some problems, you can send us more information about
> > your
> > content model and we will try to make the mapping together.
> >
> > br,
> > Christophe
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Same-name-siblings-with-OCM-tf4494352.html#a12821977
> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
>
>

Re: Same name siblings with OCM

Posted by Kaizer <Ka...@mastek.com>.
In my case, its not with a collection but my top level object itself would
dictate based on one of its attributes whether another object of the same
type can be stored under the same node.
For eg, I shouldnt be allowed to store 2 objects with the same "name"
attribute under the same node.




Christophe Lombart wrote:
> 
> On 9/21/07, Kaizer <Ka...@mastek.com> wrote:
>>
>>
>> Hi,
>>
>> I'm using OCM and wanted to know how Same name siblings work in this
>> case.
> 
> 
> 
> It works with collection converters. If you are using specific node types,
> you have to use the NTCollectionConverterImpl otherwise you have to use
> the
> DefaultCollectionImpl. Both converters have almost the same behavior in
> term
> of subnode name definition. By default, they use the same name for all
> subnodes. This is a predefined value like "collection-element". If the
> class-descriptor matching to the collection elements has an id (see the
> fieldescriptor definition), the id value is used to build the subnode
> name.
> There are some examples in the uni tests.
> 
> If you have still some problems, you can send us more information about
> your
> content model and we will try to make the mapping together.
> 
> br,
> Christophe
> 
> 

-- 
View this message in context: http://www.nabble.com/Same-name-siblings-with-OCM-tf4494352.html#a12821977
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.


Re: Same name siblings with OCM

Posted by Christophe Lombart <ch...@gmail.com>.
On 9/21/07, Kaizer <Ka...@mastek.com> wrote:
>
>
> Hi,
>
> I'm using OCM and wanted to know how Same name siblings work in this case.



It works with collection converters. If you are using specific node types,
you have to use the NTCollectionConverterImpl otherwise you have to use the
DefaultCollectionImpl. Both converters have almost the same behavior in term
of subnode name definition. By default, they use the same name for all
subnodes. This is a predefined value like "collection-element". If the
class-descriptor matching to the collection elements has an id (see the
fieldescriptor definition), the id value is used to build the subnode name.
There are some examples in the uni tests.

If you have still some problems, you can send us more information about your
content model and we will try to make the mapping together.

br,
Christophe