jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Mueller <muel...@adobe.com>
Subject Re: [jr3] Tree model
Date Mon, 05 Mar 2012 09:20:04 GMT
Hi,

>Alternatively, to avoid such vagueness without imposing performance
>penalties on large, flat nodes, we could define two different
>iteration orders, one for the explicitly specified order and a native,
>more efficient one.

It guess it would speed up reading only a little bit. The main performance
penalty for orderable child node lists is when writing (as both the
insertion order and the name lookup order need to be maintained).

Maybe we should go for "always orderable" child node lists, simply to
avoid confusion. Even if it's a bit slower.

>Note that if we do mandate orderability on child nodes, supporting
>SNSs on the MK level becomes much less of an issue as the internal
>storage model needs to be (at least some form of) a list instead of
>just a map.

I think SNS would still be a big problem :-)

>Anyway, I'm OK with explicitly scoping out SNSs from the
>MK level for now, though we may want or need to revisit that decision
>depending on how complex implementing SNSs on a higher level turns out
>to be.

True.

>OK. Something like this perhaps:
>
>    /**
>     * Returns the named property. The name is an opaque string and
>     * is not parsed or otherwise interpreted by this method.
>     * <p>
>     * The namespace of properties and child nodes is shared, so if
>     * this method returns a non-<code>null</code> value for a given
>     * name, then {@link #getNode(String)} is guaranteed to return
>     * <code>null</code> for the same name.
>     *
>     * @param name name of the property to return
>     * @return named property, or <code>null</code> if not found
>     */
>    Property getProperty(String name);
>
>    /**
>     * Returns the named child node. The name is an opaque string and
>     * is not parsed or otherwise interpreted by this method.
>     * <p>
>     * The namespace of properties and child nodes is shared, so if
>     * this method returns a non-<code>null</code> value for a given
>     * name, then {@link #getProperty(String)} is guaranteed to return
>     * <code>null</code> for the same name.
>     *
>     * @param name name of the child node to return
>     * @return named child node, or <code>null</code> if not found
>     */
>    Node getNode(String name);

Sounds good to me.

>Note that I used the terms Node, Property and ChildNodeEntry above
>since they are probably the most familiar to people. However, to avoid
>confusion with related JCR interfaces and existing Jackrabbit
>internals, it might be a good idea to use some other naming pattern.
>Following my original Tree draft (which would work nicely with Oak as
>the codename ;-), we could for example use terms Tree, Leaf and
>Branch, respectively.

So in your model a "tree" is a node? A "leaf" is a property? What is a
branch, a "child node"?


I prefer using the same terms for the same things consistently. A node
shouldn't sometimes be called node and sometimes tree. I understand we
have a naming conflict here with javax.jcr.Node and Property, but what
about name combinations:

- NodeData
- PropertyData
- ChildList


I know it sounds quite boring :-) but it would help avoid confusion a lot.
I don't want to sound like a teacher, but using names consistently is
described in many books about programming, for example "The Pragmatic
Programmer" chapter "Domain Languages".


Regards,
Thomas


Mime
View raw message