On 18 Feb 2010, at 13:04, Stefan Guggisberg wrote:
On Wed, Feb 17, 2010 at 5:17 PM, Jukka Zitting jukka.zitt...@gmail.com
wrote:
Hi,
This one's a quite frequently asked feature. Currently we store the
full list of child nodes in the same bundle or node state record with
the parent node.
About micro-kernel: I think the micro-kernel shouldn't have to support
splitting large child lists into smaller lists. That could be done on
a higher level. What it should support is all the features required by
this mechanism:
- Support 'hidden' nodes (those are marked using a hidden property).
Hi,
I would also use a b-tree structure. If a node has too many child
nodes, two new invisible internal nodes are created, and the list of
child nodes is split up. Those internal nodes wouldn't have any
properties.
For efficient path lookup, the child node list should be sorted by
name. This is
On Thu, Feb 18, 2010 at 12:34, Thomas Müller thomas.muel...@day.com wrote:
I would also use a b-tree structure. If a node has too many child
nodes, two new invisible internal nodes are created, and the list of
child nodes is split up. Those internal nodes wouldn't have any
properties.
You
Hi,
I would also use a b-tree structure. If a node has too many child
nodes, two new invisible internal nodes are created, and the list of
child nodes is split up. Those internal nodes wouldn't have any
properties.
You mean a b-tree for each node? I think this could be a separate
index,
On Wed, Feb 17, 2010 at 5:17 PM, Jukka Zitting jukka.zitt...@gmail.com wrote:
Hi,
This one's a quite frequently asked feature. Currently we store the
full list of child nodes in the same bundle or node state record with
the parent node. This makes it expensive to support nodes with large
Hi,
On Thu, Feb 18, 2010 at 2:01 PM, Thomas Müller thomas.muel...@day.com wrote:
The repository is one large b-tree, and each JCR node is a b-tree node
(except for the JCR nodes that don't have any child nodes: those are
b-tree leaves).
I don't think we can model the entire repository as a
Hi,
A Jackrabbit repository is some kind of b-tree - just that the pages
never split and balanced automatically. Maybe using b-tree is
confusing? Let's call it manual b-tree then.
i agree that flat hierarchies is an important feature, however we
shouldn't compromise
the performance for the
this message in context:
http://n4.nabble.com/jr3-Flat-hierarchy-tp1558925p1560288.html
Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
Hi,
I think Jukka is correct that the correct use of B-trees is to use one for
each list of child nodes, not as a way to model the entire hierarchy.
If you are more comfortable with this view, that's OK. I probably
should have said: the whole repository is a tree data structure.
And there
--
View this message in context:
http://n4.nabble.com/jr3-Flat-hierarchy-tp1558925p1560524.html
Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
Hi,
JCR requires lookup of children by name and/or position (for orderable
children), so the implementation needs to support all these cases
efficiently. The trickiest one to handle is probably Node.getNodes(String
namePattern) because it requires using both name and position together.
. Of the use cases I'm aware of for flat
hierarchies, none require an ordering of the children anyway, so this might
be an acceptable limitation in the implementation.
Jeff
--
View this message in context:
http://n4.nabble.com/jr3-Flat-hierarchy-tp1558925p1560650.html
Sent from the Jackrabbit - Dev
Hi,
Even without using orderBefore, the specification still requires a stable
ordering of children for nodes that support orderable child nodes (see 23.1
of JCR 2.0 spec).
Thanks for the link! I see now my idea violates the specification
which says (23.3) When a child node is added to a node
rely on?
Jeff
--
View this message in context:
http://n4.nabble.com/jr3-Flat-hierarchy-tp1558925p1560831.html
Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
On Thu, Feb 18, 2010 at 22:04, Jeff Yemin jeff.ye...@gmail.com wrote:
Thomas Müller-2 wrote:
You are right. Unfortunately orderable child nodes is the default.
Where in the spec does it say what the default is for orderable child nodes?
The only place I see it is in the CND for
On 2/18/10 4:27 PM, Alexander Klimetschek wrote:
On Thu, Feb 18, 2010 at 22:04, Jeff Yemin jeff.ye...@gmail.com wrote:
Thomas Müller-2 wrote:
You are right. Unfortunately orderable child nodes is the default.
Where in the spec does it say what the default is for orderable child nodes?
The
On Thu, Feb 18, 2010 at 22:36, Justin Edelson justinedel...@gmail.com wrote:
Perhaps JR3 should define a node type called unstructured-unordered :)
Would be non-standard, of course.
He he ;-) But this could simply be documented clearly, eg. in the FAQ,
and provide a sample node type my:bigpile
can be modified as a result of an
insertion or deletion.
Also, it seems to me that technically we're probably talking about a B+
tree, as it makes sense that the real child nodes would all be pointed to
from the leaf nodes.
Jeff
--
View this message in context:
http://n4.nabble.com/jr3-Flat
Hi,
This one's a quite frequently asked feature. Currently we store the
full list of child nodes in the same bundle or node state record with
the parent node. This makes it expensive to support nodes with large
amounts (1k) of child nodes.
The obvious solution to this problem is to use a data
20 matches
Mail list logo
