You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Naseeruddin Mohammad <na...@gmail.com> on 2007/02/18 14:27:54 UTC
Complex Hierarchy best practices
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.
-Root Node
----Departments (Node)*
------ Department Description Document (Property)
------ Department Motto Description (Property)
------ Department Location (Property)
------ Sub Departments (Node)* (Has the same structure of Department)
------ Events (node)*
------------- Events Name and Description (Property)
------ 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)
------------------------ Events (Node)*
-------------------------------- Events Name and Description (Property)
TIA,
Nas.
Re: Complex Hierarchy best practices
Posted by Michael Neale <mi...@gmail.com>.
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 <na...@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 <ju...@gmail.com> wrote:
> >
> > Hi,
> >
> > On 2/18/07, Naseeruddin Mohammad <na...@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
> >
>
Re: Complex Hierarchy best practices
Posted by Naseeruddin Mohammad <na...@gmail.com>.
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 <ju...@gmail.com> wrote:
>
> Hi,
>
> On 2/18/07, Naseeruddin Mohammad <na...@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
>
Re: Complex Hierarchy best practices
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 2/18/07, Naseeruddin Mohammad <na...@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