On 7 Oct 2009, at 16:38, Alexander Klimetschek wrote:
On Wed, Oct 7, 2009 at 16:48, Ian Boston <i...@tfd.co.uk> wrote:
On 7 Oct 2009, at 14:50, Alexander Klimetschek (JIRA) wrote:
I would refrain from building in an automatic mechanism that creates
hash-based paths because they are bad ;-)
Could you elaborate on why they are bad in the JCR ?
(not taking about in URLS exposed to users here, only the JCR)
I think the answer already lies in a) having a URL structure for the
public + hashes as jcr paths and b) mapping between them. Why
shouldn't the nice/intuitive/readable structure that the web users see
(and expect) not be used in the JCR?
agreed
A custom or special mapping should only be the exception (eg. the
~user directory you mentioned).
agreed
A common and understandable content structure makes everything simpler
- any kind of mapping unnecessarily complicates the life for
developers, administrators and other technical users: they have to
handle two different models and it's often application logic involved
to find the items in question, which is hard to achieve manually. (The
same goes for looking up JCR nodes in a typical db bundle persistence
manager - it's not intended for the user, but here it's an independent
implementation detail).
agreed,
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 ?
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.
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 ?
Ian
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetsc...@day.com
