I think there is a use case for large flat unordered lists (using a node
type with orderable = false). For example, dictionaries, where the key and
value are in the properties and the node name is not really relevant, and
where you don't want to create nested structures just for the sake of
Hi,
On Sat, Jan 21, 2012 at 11:37 PM, Tobias Bocanegra tri...@adobe.com wrote:
so for large childnode lists, a stable but uncontrollable order
would be ok, although violating the spec?
I wouldn't violate the spec for this. If you have an orderable node
(like nt:unstructured), then the
Hi,
Am 23.01.2012 um 10:43 schrieb Jukka Zitting:
Hi,
On Sat, Jan 21, 2012 at 11:37 PM, Tobias Bocanegra tri...@adobe.com wrote:
so for large childnode lists, a stable but uncontrollable order
would be ok, although violating the spec?
I wouldn't violate the spec for this. If you have an
On 23.01.12 11:43, Felix Meschberger fmesc...@adobe.com wrote:
Wouldn't it be such, that unordered might mean no defined but stable
ordering while ordered means insertion order unless eplicitly changed ?
+1
Alex
--
Alexander Klimetschek
Developer // Adobe (Day) // Berlin - Basel
On Sat, Jan 21, 2012 at 11:37 PM, Tobias Bocanegratri...@adobe.com wrote:
so for large childnode lists, a stable but uncontrollable order
would be ok, although violating the spec?
I wouldn't violate the spec for this. If you have an orderable node
(like nt:unstructured), then the repository
On 2012-01-23 11:43, Felix Meschberger wrote:
...
I am not sure, whether this proposal does not open a can of worms: Consider
using a node for child nodes whose retrieval should be ordered by insertion
order. This is currently guaranteed by switching on ordered child nodes on the
parent node,
On Sat, Jan 21, 2012 at 3:00 AM, Tobias Bocanegra tri...@adobe.com wrote:
nt:unstructured has orderable childnodes, and we also preach to use
nt:unstructured whereever you can. Also, i assume that a lot of
applications benefit from node ordering (like a CMS). So I think that
the majority of
I agree,
so for large childnode lists, a stable but uncontrollable order would
be ok, although violating the spec?
--
toby
On Sat, Jan 21, 2012 at 5:04 AM, Stefan Guggisberg
stefan.guggisb...@gmail.com wrote:
On Sat, Jan 21, 2012 at 3:00 AM, Tobias Bocanegra tri...@adobe.com wrote:
Hi,
The current Jackrabbit implementation uses orderable child nodes by default,
meaning nodes are returned in the same order as they are created. As an
example, if I create the nodes /test/c, then /test/b, and then /test/a, and
then read the node list, I will get them back in that same order.
On 2012-01-20 16:09, Thomas Mueller wrote:
Hi,
The current Jackrabbit implementation uses orderable child nodes by
default, meaning nodes are returned in the same order as they are
created. As an example, if I create the nodes /test/c, then /test/b, and
then /test/a, and then read the node
Hi,
I guess one problem is that the default node type, nt:unstructured,
supports orderable child nodes:
http://www.day.com/specs/jcr/2.0/3_Repository_Model.html#3.7.13.1%20nt:unst
ructured This node type also supports client-orderable child nodes. I
guess client-orderable also means insertion
On 20.01.12 16:09, Thomas Mueller
muel...@adobe.commailto:muel...@adobe.com wrote:
The current Jackrabbit implementation uses orderable child nodes by default,
meaning nodes are returned in the same order as they are created.
I think same order as they are created is not really orderable child
Hi,
Isn't the current appending the simplest and fastest?
No. It requires to keep two indexes: one by number, and one by name.
Having only one index (by name) is about twice as fast, and needs about
half the disk space / memory.
Regards,
Thomas
On 20.01.12 16:50, Thomas Mueller muel...@adobe.com wrote:
Isn't the current appending the simplest and fastest?
No. It requires to keep two indexes: one by number, and one by name.
Having only one index (by name) is about twice as fast, and needs about
half the disk space / memory.
Ah, I guess
Hi,
On Fri, Jan 20, 2012 at 4:35 PM, Thomas Mueller muel...@adobe.com wrote:
If we use alphabetical child node lists by default for Jackrabbit 3, then
we would need to use a different default node type?
Right, though I suppose there are quite a few applications that use
nt:unstructured either
On Fri, Jan 20, 2012 at 4:09 PM, Thomas Mueller muel...@adobe.com wrote:
Hi,
The current Jackrabbit implementation uses orderable child nodes by default,
meaning nodes are returned in the same order as they are created. As an
example, if I create the nodes /test/c, then /test/b, and then
Hi,
Thinking about this more generally, it would definitely be useful to
be able to use a more efficient underlying storage for unorderable
nodes. However, there still are hard use cases that require us to
support orderable nodes as indicated by the type of the parent node.
Thus the
On Fri, Jan 20, 2012 at 4:56 PM, Jukka Zitting jukka.zitt...@gmail.com wrote:
Hi,
On Fri, Jan 20, 2012 at 4:35 PM, Thomas Mueller muel...@adobe.com wrote:
If we use alphabetical child node lists by default for Jackrabbit 3, then
we would need to use a different default node type?
Right,
On Fri, Jan 20, 2012 at 5:43 PM, Jukka Zitting jukka.zitt...@gmail.com wrote:
Hi,
Thinking about this more generally, it would definitely be useful to
be able to use a more efficient underlying storage for unorderable
nodes. However, there still are hard use cases that require us to
support
nt:unstructured has orderable childnodes, and we also preach to use
nt:unstructured whereever you can. Also, i assume that a lot of
applications benefit from node ordering (like a CMS). So I think that
the majority of the repositories have a lot of nodes with ordered
childnodes. thus i would not
20 matches
Mail list logo