Re: node.hasNodes() ,node.getNodes() and removing nodes with node.remove()

2017-08-08 Thread Chetan Mehrotra
> Is using this nextNode (linked list built on Node properties) the best > practice for when ordering AND large numbers of children are an absolute > requirement? What do you guys think? Crazy idea or reasonable? Thats can be an option. However concurrent updates would result in conflicts which

Re: node.hasNodes() ,node.getNodes() and removing nodes with node.remove()

2017-08-07 Thread Clay Ferguson
I was unaware simply making nodes unorderable would allow good scalability. Good to know! I guess we could always experiment with using a nextNode property to allow iterating in order, and also get good scalability for inserting/deleting, but using that linked-list approach would be slow at

Re: node.hasNodes() ,node.getNodes() and removing nodes with node.remove()

2017-08-07 Thread Julian Reschke
On 2017-08-07 03:39, Clay Ferguson wrote: Two thoughts: 1) It's a known issue (severe weakness) in the design of Jackrabbit/Oak that it chokes like a dog on large numbers of child nodes all under the same node. Many users have struggled with this, and imo it has been one of the massive flaws

Re: node.hasNodes() ,node.getNodes() and removing nodes with node.remove()

2017-08-06 Thread Peter Harrison
Thanks for the reference. Much appreciated. On Mon, Aug 7, 2017 at 4:15 PM, Chetan Mehrotra wrote: > > Every addition of a child node implies a change to the parent node > Document > > Looks like the parent nodetype is nt:unstructured which requires > orderable

Re: node.hasNodes() ,node.getNodes() and removing nodes with node.remove()

2017-08-06 Thread Chetan Mehrotra
> Every addition of a child node implies a change to the parent node Document Looks like the parent nodetype is nt:unstructured which requires orderable children. If you do not require that use a nodetype like oak:Unstructured. See [1] for some background Chetan Mehrotra [1]

Re: node.hasNodes() ,node.getNodes() and removing nodes with node.remove()

2017-08-06 Thread Peter Harrison
1) I knew many nodes under one node was an issue with 2.X but I thought Oak was going to address this issue. To get a better grasp of what is going on I took a look at the data structure in Mongo. It seems to be a 'flat' node Collection. There is a Collection called 'nodes'. A document in this

Re: node.hasNodes() ,node.getNodes() and removing nodes with node.remove()

2017-08-06 Thread Clay Ferguson
​Peter, Also as a last resort if absolutely nothing else is workable, you could theoretically run an Export to XML, and then process that XML with custom code you write, and THEN re-import back into a new empty repo.​ Please share your solution with the group if you would, once found. Adobe might

Re: node.hasNodes() ,node.getNodes() and removing nodes with node.remove()

2017-08-06 Thread Clay Ferguson
Two thoughts: 1) It's a known issue (severe weakness) in the design of Jackrabbit/Oak that it chokes like a dog on large numbers of child nodes all under the same node. Many users have struggled with this, and imo it has been one of the massive flaws that has kept the JCR from really taking off.