jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Neale" <michael.ne...@gmail.com>
Subject Re: Complex Hierarchy best practices
Date Wed, 21 Feb 2007 05:59:50 GMT
look for the *.ddl files (or .sql ? I can't remember) in the jackrabbit
source will show you the schema used.

On 2/20/07, Naseeruddin Mohammad <naseer.md@gmail.com> wrote:
>
> Jukka,
>
>      I got it, after going through your suggestions I got a better
> understanding of how things work  w.r.t JCR.
>
>      To convience my self can I actually see the data model created by
> jackrabbit.
>
> Can you tell me exactly which which persistant manager and FileSystem
> component should be used, to see the ER diagram of the relational tables?
>
> Thanks for your feedback,
> Naseer.
>
> On 2/19/07, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> >
> > Hi,
> >
> > On 2/18/07, Naseeruddin Mohammad <naseer.md@gmail.com> wrote:
> > > I have the following hierarchy to take care of, I am not sure that if
> I
> > > blindly use the JCR APIs to create this structure the resulting
> > datamodel
> > > will be effecient, as my hierarchy is deep as well as wide. Please
> > provide
> > > your thoughts, feedback and options avilalable for me to address this
> > Issue.
> >
> > Looks nice on the outset. Some comments inline.
> >
> > > -Root Node
> >
> > It is generally a good idea to have an application-specific root node,
> > like /my:content where my is your namespace prefix, under which you
> > file all your content. This helps with backups and queries as you
> > don't need to explicitly exclude /jcr:system or any other extra
> > content within the root.
> >
> > Using your own namespace for that node avoids any collisions with
> > other applications you may want to include in the same workspace. Also
> > as a general rule (best practice even?), I usually use namespace
> > prefixes for nodes and properties whose names are fixed in my
> > application and put all user-entered names in the default namespace
> > without a prefix.
> >
> > > ----Departments (Node)*
> > > ------ Department Description Document (Property)
> > > ------ Department Motto Description (Property)
> > > ------ Department Location (Property)
> >
> > Is the Document a full document file like a PDF or just a text field?
> > In the former case you should probably store it as an nt:file node.
> > The same goes for the other "Document" properties in your model.
> >
> > > ------ Events (node)*
> > > ------------- Events Name and Description (Property)
> >
> > If you're planning to keep a full archive of all events over time,
> > then you may want to introduce some sort of an internal hierarchy, for
> > example an extra hierarchy level for each year or even month. A single
> > level is generally fine for up to 100-1000 child nodes, but once you
> > go higher than that it's better to introduce such an extra hierarchy
> > level both for performance and ease of navigating the content
> > structure.
> >
> > > ------ Projects (Node)*
> > > ------------- Project Descirption Document (Property)
> > > ------------- Project Planning Document (Property)
> > > ------------- Project etc etc Documents (Property)
> > > ------------- Team ( Node)*
> > > ------------------------Team Name and Description (Property)
> > > ------------------------Team Location (Property)
> > > ------------------------Team Active Hours (Property)
> >
> > Will the teams be project-specific or more permanent entities that you
> > just assign to different projects? In the latter case you probably
> > want to store the team information higher up independent of individual
> > projects, and use a (multi-valued) REFERENCE property to link from a
> > project to the teams working on it.
> >
> > BR,
> >
> > Jukka Zitting
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message