jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anton Slutsky (JIRA)" <j...@apache.org>
Subject [jira] Updated: (JCR-322) Support node type modification and removal
Date Wed, 07 Feb 2007 17:34:06 GMT

     [ https://issues.apache.org/jira/browse/JCR-322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Anton Slutsky updated JCR-322:

    Attachment: nodetyperegistry.patch

After a lengthy discussion here: http://www.nabble.com/NodeTypeRegistry.checkForReferencesInContent%28%29-tf2882955.html
(tried to move the thread to the developer forum, but got rejected for some reason), attached
is a proposed implementation.

What this does is, it takes a fairly simplistic "fail-fast" approach.  checkForReferencesInContent()
executes a query on each workspace searching for nodes of a given type.  If any are found,
it doesnt try to fix the type, but rather throws a RepositoryException, forcing the caller
to deal with its own data issues.

There are two major issues with this implementation (see thread)
1. Searching is done by utilizing a query manager, which in turn uses indexes that are outside
the physical node storage.  This could be a problem, but currently nothing else will scale.

2. Concurrency.  There are four concurrency related use cases that I can forsee at this point.
  a. Not REALLY a concurrency issue, but needs to be addressed.  Node is added by a call to
addNode(), type is deleted, session is saved by a call to ItemImpl.save() (it looks like everything
calls ItemImpl.save() in the end of the day).  
    In this case, I dont think much care needs to be taken.  All that will happen is, a NoSuchNodeTypeFound
exception will be thrown.  Which, I think, is fine.
  b. Node type is deleted, new node of type we just deleted is added, session is saved.  
   Same as above.  Also not a real concurrency  issue, but has to be brough up.  Let it throw

  c. Now here is the interesting case.  While checkForReferenciesInContent() is running, a
node of the given type is being persisted by a call to save().
  I saw a lot of discussion on the subject, so I'm pretty sure I'm missing something here,
but it seems to me that since we know that no two instances of the RepositoryImpl class are
supposed to operate on any given physical repository (see thread), all we really have to do
is synchronized ItemImpl.save() and NodeTypeRegistry.checkForReferencesInContent() on the
repository object.  

And that is what the attached patch tries to do :-).  Other then these concerns that I just
brought up, one more thing kind of bothers me.  In order to check each workspace, I had to
get a SystemSession.  To do that, I had to expose the RepositoryImpl.getSystemSession() method
as public.  Do feel free to express your opinions on this.

> Support node type modification and removal
> ------------------------------------------
>                 Key: JCR-322
>                 URL: https://issues.apache.org/jira/browse/JCR-322
>             Project: Jackrabbit
>          Issue Type: New Feature
>          Components: nodetype
>    Affects Versions: 0.9, 1.0
>            Reporter: Jukka Zitting
>         Attachments: nodetyperegistry.patch
> There is currently no way to modify or remove registered node types. The existing reregister
and unregister methods in NodeTypeRegistry  throw "not yet implemented" exceptions for anything
else than trivial node type changes.
> JSR 283 is working on an node type management API that we should ultimately implement.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message