jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@day.com>
Subject Re: Content structure and resulting SPI implementation
Date Thu, 05 Jun 2008 07:49:33 GMT
hi pierre

> My question concerned the better way to reflect the content structure in an
> SPI implementation.
> I saw that the RepositoryInterface declared some interesting method like
> getNodeInfo, getPropertyInfo and getChildInfo.

and getItemInfos.

- getItemInfos: retrieve a NodeInfo and optionally additional NodeInfos
                 or PropertyInfos (from below that node). batched read.
- getNodeInfo : basically replaced by getItemInfos
- getPropertyInfo: retrieve a single property info.
- getChildInfo: retrieve name/index/id of all child-nodes of a node.
   see also the following jira issues: JCR-1405, JCR-1239

> Considering that the choice between getNodeInfo, getPropertyInfo and
> getChildInfo was function of the type of the item on which the path pointed
> (but maybe I'm wrong ?), 

see above

> I was thinking of trying to parse the ItemId path
> in order to decide what have to be done for each item type (node, property
> ...) in function of its path (giving it a semantic from my data model's
> point of view).

not quite. the type of item (Property or Node) is defined by
the ItemId (see ItemId#denotesNode). there is never an unspecified
item type. or do you mean something different?

> So in this hypothesis we get the following choice hierarchy :
> First : function of the type of the ItemId.
> Second : function of the path of the ItemId.
> From the point of view of what the *Info method have to handle, I was
> thinking first of the hierarchy (giving each item a parent Id for example)
> and then to the data (reading it directly from my data model, a database
> thanks to the intermediary of a JDBC API). Did I forget something ?

sorry, i didn't get that.


View raw message