jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Guggisberg (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-954) Allow to disable referential integrity checking for workspace
Date Fri, 29 Feb 2008 11:10:51 GMT

    [ https://issues.apache.org/jira/browse/JCR-954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12573682#action_12573682
] 

Stefan Guggisberg commented on JCR-954:
---------------------------------------

>  How about including the method in a custom RepositoryImpl subclass included in o.a.j.core?
This way nobody would be affected by default, but if you really needed this feature you could
instantiate and use that subclass instead of the normal RepositoryImpl.

-0

IMO that would be still too easy and tempting to use. people might start using this 'feature'
because they expect better performance. 
however, unless they know exactly what they're doing, they risk corrupting the repository.
personally i'd prefer to expose this 
functionality to subclasses but people would have to write their own in order to enable it.


> Allow to disable referential integrity checking for workspace
> -------------------------------------------------------------
>
>                 Key: JCR-954
>                 URL: https://issues.apache.org/jira/browse/JCR-954
>             Project: Jackrabbit
>          Issue Type: New Feature
>          Components: jackrabbit-core
>            Reporter: Przemo Pakulski
>            Priority: Minor
>             Fix For: 1.3.4, 1.5
>
>         Attachments: JCR-954-patch.txt, JCR-954-simple.diff
>
>
> Some operations like clone, remove operating on huge subtree of nodes requires a lot
of memory. To copy, clone, remove subtree all nodes are loaded into transient spaces. It allows
such operations to be transactional, from other side it requires a lot of heap size and this
memory size is directly dependent on the size of subtree (number of nodes). In result of this
in some cases it is impossible to make such operations in one step. In our environment sometimes
1 GB of java heap is not enough to succesfully clone subtree  from one workspace to another.
> You can always clone (copy, remove) tree in chunks, but if you have references between
subtrees such approach fails. Possibilty of temporary disabling referential integrity checking
for experienced JCR user could be very usefull then.
> Another use case is to allow to clone selected subtrees of the whole structure between
worskpaces. In our application we need to clone only some selected subtrees from one workspace
to another. But we can not do that because of existing references. We need to clone the whol
estructure first, then remove all unwanted nodes, which is really time expensive and memory
consuming.

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


Mime
View raw message