Generating unique path

[Nigel Sim]

Hi,

In my use case for Jackrabbit I do not have a direct use for paths. I just
have object with properties and relationships which I want to store, and
later retrieve via searching those attributes.

Is there a way/class/factory I can use to auto generate a unique path
property?

Cheers
Nigel

[Alexander Klimetschek]

On Tue, Jul 7, 2009 at 12:20 PM, Nigel Sim<[hidden email]> wrote:
> In my use case for Jackrabbit I do not have a direct use for paths. I just
> have object with properties and relationships which I want to store, and
> later retrieve via searching those attributes.

If you really want to do this, I don't think JCR is the right choice
for you. But I strongly suggest to look for hierarchical structures in
your data from which you can build the paths.

> Is there a way/class/factory I can use to auto generate a unique path
> property?

No, because paths should always make sense to the developer/user.

Regards,
Alex

--
Alexander Klimetschek
[hidden email]

[Bertrand Delacretaz-2]

On Tue, Jul 7, 2009 at 12:20 PM, Nigel Sim<[hidden email]> wrote:
> ...In my use case for Jackrabbit I do not have a direct use for paths. I just
> have object with properties and relationships which I want to store, and
> later retrieve via searching those attributes.
>
> Is there a way/class/factory I can use to auto generate a unique path
> property?...

Using time-based paths has worked well for me in similar cases, something like

  /content/2008/12/31/09/42/03/0001

where you generate a path based on the timestamp when the object is
inserted. The trailing 0001 is a global counter that prevents
collisions when several objects are inserted within the same second.

With Jackrabbit it is not recommended for a node to have more than
about 10'000 child nodes, the above convention will also avoid that.

-Bertrand

[Alexander Klimetschek]

On Tue, Jul 7, 2009 at 1:23 PM, Bertrand
Delacretaz<[hidden email]> wrote:
> Using time-based paths has worked well for me in similar cases, something like
>
>  /content/2008/12/31/09/42/03/0001
>
>  [..]
>
> With Jackrabbit it is not recommended for a node to have more than
> about 10'000 child nodes, the above convention will also avoid that.

Well, this might lead to a y10k problem then....

SCNR ;-)

But Bertrand is right, most data has a date associated, so this is a
good solution for many cases. You can still use UUIDs if you make the
respective nodes mix:referenceable (but note that the UUIDs will be
generated by the repository).

Regards,
Alex

--
Alexander Klimetschek
[hidden email]

[Nigel Sim]

Thanks Bertrand, That sounds like a good idea. I assume that the "global
counter" is stored in the app that is accessing Jackrabbit, or is it
actually an object in the repository which you can perform an atomic
increment on?

Nigel

2009/7/7 Bertrand Delacretaz <[hidden email]>

> On Tue, Jul 7, 2009 at 12:20 PM, Nigel Sim<[hidden email]> wrote:
> > ...In my use case for Jackrabbit I do not have a direct use for paths. I
> just
> > have object with properties and relationships which I want to store, and
> > later retrieve via searching those attributes.
> >
> > Is there a way/class/factory I can use to auto generate a unique path
> > property?...
>
> Using time-based paths has worked well for me in similar cases, something
> like
>
>  /content/2008/12/31/09/42/03/0001
>
> where you generate a path based on the timestamp when the object is
> inserted. The trailing 0001 is a global counter that prevents
> collisions when several objects are inserted within the same second.
>
> With Jackrabbit it is not recommended for a node to have more than
> about 10'000 child nodes, the above convention will also avoid that.
>
> -Bertrand
>

--
JCU eResearch Centre
School Of Business (IT)
James Cook University

[Bertrand Delacretaz-2]

On Tue, Jul 7, 2009 at 1:49 PM, Nigel Sim<[hidden email]> wrote:
> Thanks Bertrand, That sounds like a good idea. I assume that the "global
> counter" is stored in the app that is accessing Jackrabbit, or is it
> actually an object in the repository which you can perform an atomic
> increment on?...

It's probably good enough to store it in the app. You can also, right
before saving, check if there's already a node with the current
number, and increment if that's the case. There will usually be very
few collisions, though that depends on your usage patterns of course.

-Bertrand

>
> Nigel
>
> 2009/7/7 Bertrand Delacretaz <[hidden email]>
>
>> On Tue, Jul 7, 2009 at 12:20 PM, Nigel Sim<[hidden email]> wrote:
>> > ...In my use case for Jackrabbit I do not have a direct use for paths. I
>> just
>> > have object with properties and relationships which I want to store, and
>> > later retrieve via searching those attributes.
>> >
>> > Is there a way/class/factory I can use to auto generate a unique path
>> > property?...
>>
>> Using time-based paths has worked well for me in similar cases, something
>> like
>>
>>  /content/2008/12/31/09/42/03/0001
>>
>> where you generate a path based on the timestamp when the object is
>> inserted. The trailing 0001 is a global counter that prevents
>> collisions when several objects are inserted within the same second.
>>
>> With Jackrabbit it is not recommended for a node to have more than
>> about 10'000 child nodes, the above convention will also avoid that.
>>
>> -Bertrand
>>
>
>
>
> --
> JCU eResearch Centre
> School Of Business (IT)
> James Cook University
>