On Wed, Aug 12, 2009 at 12:54 PM, Mike Wilson<mike...@hotmail.com> wrote: > Stefan Guggisberg wrote: >> On Tue, Aug 11, 2009 at 4:51 PM, Mike Wilson wrote: >> > What is planned for Jackrabbit 2.0 regarding nodetype >> > management? Ie, regarding these features from chapter 19 in >> > the JCR 2.0 spec: >> > - Removing a node type from the registry. >> > - Updating the definition of a registered node type that is >> > currently in use as the node type of a node in the >> > repository. >> > >> > Will these be "fully" implemented to handle all sorts of >> > situations, or will implementation be similar to Jackrabbit >> > 1.x with no unregister and only limited updates? >> >> AFAIK there are currently no plans for further work on the node type >> management features you mentioned, at least not so for jackrabbit 2.0. >> so far we haven't reached consensus on how to best tackle the >> implementation challenges we're facing but we'll certainly >> address this topic >> when desiging the jackrabbit 3.0 core architecture. > > Thanks for the info, Stefan. > I take it that 3.0 is several years away?
now that jackrabbit 2.0 is soon to be released, 3.0 will probably become our mid-term goal. i hope that development will start sometime this year. if that's true, we should be able to see first results next year. however, that's just my personal rather optimistic guess. OTOH, we're certainly open to contributions if someone with a bright idea is willing to tackle this issue in jackrabbit 2.0. > > (Btw, are there any JSR-283 folks here that know if there are > other JCR implementations doing this earlier?) not sure. some implementors have chosen to represent node types as database tables in their backends. while some operations would certainly be easier to implement (e.g. through 'ALTER TABLE" stmts), others are probably pretty difficult (e.g. nt:unstructured, multi-valued properties, setPrimaryType, etc). cheers stefan > > Best regards > Mike > >
