Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (idunn.apache.osuosl.org: domain gmail.com designates
 64.233.166.176 as permitted sender)
DomainKey-Status: good
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=K7sGEDTVSm6BwpUla3kBXBwHj5jvl8LUFEW+qJBIHqoHIysI7s2qDBK+fHygjcvcSDjGUbqRiaE8O/qYLo6uzn9kHy/lpV5T2CsJLv5N8BdICUQV2gehimfrJ17IiY5JaDtzVY4Rh8KlH3W+GAEWbGhC6vreTZ3cF0PSiO21GO0=
Message-ID: <8be731880609240807j27e9f68et63debe970677652f@mail.gmail.com>
Date: Sun, 24 Sep 2006 17:07:07 +0200
From: "Tobias Bocanegra" <tobias.bocanegra@day.com>
Reply-To: tobias.bocanegra@day.com
Sender: tobias.strasser@gmail.com
To: users@jackrabbit.apache.org
Subject: Re: A few questions
In-Reply-To: <2991d56c0609240740h69dcef16u6843d548867bff16@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <2991d56c0609240740h69dcef16u6843d548867bff16@mail.gmail.com>

hi behrang,

> Does Jackrabbit support:
>
> 1- synthetic or auto-increment properties?
currently not. although there exist the 'autocreated' properties but
there is no configurable handler to initialize them. you would need to
modify jackrabbits core in order to get this.

> 2- uniqueness constraints for properties for same-name siblings?
first, same-name siblings only work for nodes. two properties of a
node can't have the same name. if same-name-siblings are allowed on a
node is defined by it's nodetype. if it's not allowed, the names of
the subnodes need to be unique.

or do you want unique keys as properties of sns ? like the 'id' property here:

/resources
  /humanresources
    /resource
       - id = "xxxxx"
    /resource
       - id = "yyyy"
    /resource
       - id = "zzzz"
    ...

no, this does not exist. but when you create a mix:referenceable node,
it's uuid is guaranteed to be unique.

basically what you do with primarykeys/forgeinkeys is rdbms, you do
with mix:referenceables and reference properties in jcr.

> Also are these two features reasonable for a content repository
> system, or am I missing something?
they are. but since autoincrement properties are not explicitely
defined by jsr170 they were not implemented in jackrabbit.

> A few guys are working on the JCR layer of an application we are
> developing. We have an entity called HumanResource which has a dozen
> of properties. One of these properties is loginName. As the loginName
> is unique and is alpha-numeric, it's decided to use it as the ID for
> the HumanResources as well. We save HumanResources under
> /resources/humanresources/ in the JCR repository. So when an end user
> (end developer actually) needs to save a new HumanResource in the
> database, he has to set the ID of the HumanResource like this:
>
>  humanResource.setID("/resources/humanresources/aLoginName");
>  humanResourceJCRDAO.save(humanResource); // saves the humanResource
> at the path "ID" in JCR
>
> As in terms of relational algebra, loginName is a natural-key,  and
> it doesn't contain characters that can't be used as a node name in
> JCR, it seems to be reasonable to work with HumanResource instances
> like above.
definitely.

>
> But then I had to now work with instances of the Position entity.
> Positions are saved at "/resources/positions/". But the Position
> entity does not have a natural key. One solution for how to save
> Position instances, is to escape its positionName entry so that it can
> be used as a node name in JCR and save it like this:
>
>  String nodeName = escape(position.getPositionName());
>  position.setID("/resources/positions/" + nodeName);
>  positionJCRDAO.save(position); //saves the position at the path "ID" in JCR
>
> As position names might change over time, it is not a good idea to use
> position names as IDs, at least this is true in the relational algebra
> and RDBMs land.
>
> Another solution could be to store instances of Position under
> "/resources/position/" as same-name siblings named position and add a
> property to these position nodes named ID which is a synthetic key
> (probably an auto-increment integer or a Version-4 UUID*)
>
> Can I ask a JCR expert to consider these two solutions and verify
> which one is better? Or probably give me a better best-practice
> solution for this issue?
having  human readable nodenames is always a good thing. but in your
case, when the positionname needs to be altered, it's probably not
optimal. i would either create mix:referenceable samename siblings or
randmonly labeled position nodes.

> * - To different randomly generated Version 4 UUIDs are very unlikely
> to be equal, however it is not guaranteed that they're unequal. Is it
> safe to use such UUIDs as PKs for Tables or JCR Nodes?
yes.

regards, toby
-- 
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---