On Wed, Oct 7, 2009 at 18:10, Ian Boston <i...@tfd.co.uk> wrote: > so if the abstraction and isolation is perfect and the hashed and ugly jcr > path never exposed to a developer or user above the layer of service or api, > then using them in the JCR itself is unfortunate but acceptable ?
I'd say the "layer of service or api" is the JCR API and that's exposed to developers. With Sling, this is certainly the case. > It would obviously be desirable not to have to resort to hashing, but there > are cases as soon as a system has more than a few 10K users. Yes, but I am just saying that a somehow senseful naming is preferred over arbitrary hashes. Dates like 2009/12/01 or nodename prefixes "a/ad/admin" or more domain specific categorization. > Longer term, looking at the storage of child nodes relative to parents in > Jackrabbit itself *might* address this. You mention the Persistance Manager. > Are there PM's that dont have the problem or is it above the PM layer ? I was just using this as an analogy; it affects most persistence managers, but especially the optimized bundle pms. They store nodes by uuid and as a binary bundle in the database, so accessing the database (for doing JCR workarounds for migration, large-style copying or whatever) is not anything that really works because you cannot browse it without additional programming help. But every now people on the Jackrabbit list, that are new to JR, ask for that: how can I modify the nodes in the db, etc. That's because they want to reuse their experience with databases and all the admin tools available. Now with JCR, if you have a JCR-level browser and admin tool, you don't need it. And the PM is just an implementation detail. So IMO this is a good thing - one that gives you the unstructuredness. But above that level you don't want to introduce such a complex mapping so that people have no way to use the repository as a fundamental infrastructure. Regards, Alex -- Alexander Klimetschek alexander.klimetsc...@day.com
