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

Jukka Zitting updated JCR-954:
------------------------------

    Affects Version/s:     (was: 1.5)
                           (was: 1.4.1)
                           (was: 1.3.3)
                           (was: 1.4)
        Fix Version/s:     (was: 1.4.1)

Agreed with Przemo. There's a real itch here and the proposed fix won't harm 
anyone, so unless someone comes up with another way to fix this we should not 
stand in the way.

About the fix, how would you enable the no-referential-checks mode in practice? 
Should we add some route up to the RepositoryImpl or WorkspaceImpl level, or 
should the checkReferences flag perhaps be static?

> 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.

Reply via email to