On Tue, Jul 7, 2009 at 1:49 PM, Nigel Sim<[email protected]> 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 <[email protected]> > >> On Tue, Jul 7, 2009 at 12:20 PM, Nigel Sim<[email protected]> 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 >
