jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicolas Dufour" <nrduf...@gmail.com>
Subject Re: Are the node types the root of evil ?
Date Tue, 15 Apr 2008 14:13:30 GMT
In fact, I'm extremely tempted that our next version will include only
nt:unstructured node types and everything will be controlled
programmatically.

Even export/import could be a pain, specially if the site cant be down for a
long time.
If I can create a background migration system I will be happy ;)

Nicolas

On Mon, Apr 14, 2008 at 1:08 PM, Tobias Bocanegra <tobias.bocanegra@day.com>
wrote:

> it depends on the use case. but in general i agree that
> nt:unstructured is sufficient for most apps.
> the restriction that nodetypes can't be changed (reregistered) is a
> problem of jackrabbit which will be fixed soon. also the lack of
> altering the nodetypes of existing node is something that is addressed
> in jcr283.
>
> stefano and david wrote some interesting articles about that:
>
> http://wiki.apache.org/jackrabbit/DavidsModel
> http://www.betaversion.org/~stefano/linotype/news/93/<http://www.betaversion.org/%7Estefano/linotype/news/93/>
>
> --
> regards, toby
>
>
> On 4/14/08, Ivan Latysh <ivanlatysh@gmail.com> wrote:
> > Charles Johnson wrote:
> >
> >
> > > Surely this is analagous to constraints and referential integrity
> through
> > key relationships in the RDBMS model? The same things could be said
> about
> > dispensing with anything other than application layer integrity and
> > validation in that model.
> > >
> >  You can alter RDBMS structure, when JR missing such functionality.
> >  (I haven't checked latest release, yet)
> >
> >  So unless you are 200% sure of what you have to have, don't use
> NodeTypes.
> >
> >  So far we alter structure this way:
> >  backup (with JCR-Backup) -> change node types -> create new repo ->
> update
> > backed-up XML -> restore it.
> >
> >  --
> >  Ivan Latysh
> >  IvanLatysh@gmail.com
> >
>



-- 
Nicolas Dufour
nrdufour@gmail.com

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