jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Behrang Saeedzadeh" <behran...@gmail.com>
Subject A few questions
Date Sun, 24 Sep 2006 14:40:08 GMT
Hi,

First, a few questions:

Does Jackrabbit support:

1- synthetic or auto-increment properties?

2- uniqueness constraints for properties for same-name siblings?

Also are these two features reasonable for a content repository
system, or am I missing something?

Plus,

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.

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?

* - 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?

Thanks in advance,
Behrang
-- 
"We can only see a short distance ahead,
but we can see plenty there
that needs to be done." - Alan Turing

"Science is a differential equation. Religion
is a boundary condition" - Alan Turing

Behrang Saeedzadeh
http://www.jroller.com/page/behrangsa
http://my.opera.com/behrangsa

Mime
View raw message