[
https://issues.apache.org/jira/browse/JCR-954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500355
]
Przemo Pakulski commented on JCR-954:
-------------------------------------
I can agree that such feature is rather workaround, but this solution is quick
and really works. As I wrote it will be not recommended to use it, it is only
for experience JCR users which will be aware of any possible drawbacks.
>From other point of view using any relational database you can also temporarly
>disable constraint checking to speedup some bulk operations, then enable it
>again. And in some cases it is very helpfull.
>references are a core feature of jsr-170 which imo must not be compromised
>through public api methods.
I dot't need it exposed through public API. What I need is to have some methods
which I can call on any component (could be RepositoryImpl, or WorkspaceImpl).
For now we have implemented this by extending SISM class and overriding some
methods. But then our code is depenedent on Jackrabbit, and could stop work
with newest versions.
>Consider a big subtree of items (1 mio items, eg.), which you might want to
>delete. Just switching off integrity checks does not help here
I think it helps, because you can remove tree in steps without worrying about
references.
>we should address the real issue instead.
I really agree with you, but changing this could mean redesigning of jackrabbit
core and it does not look that it could happen in the near future.
Stefan, Felix, could you recommend any other feasible solution for my use cases?
> 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: core
> Reporter: Przemo Pakulski
> Fix For: 1.4
>
> Attachments: JCR-954-patch.txt
>
>
> 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.
