[Cps4] cps/jcr document mapping

[Florent Guillaume]

On 6 Apr 2006, at 19:23, Bogdan Stefanescu wrote:
> It's ok from Apogee point of view.. in fact we have no requirements
> about the model  implementation.
> Apogee should be able to adapt itself to any type of repository  
> model -
> so we only need to know exactly how the cps model will be  
> structured to
> be able to implement adapters to plug it into Apogee

Ok, the point is really that we want to be as "natural" as possible  
for the JCR, so that a plugin to a non-CPS JCR would be nearly the same.

> Some comments:
>
>> A CPS document's attributes are stored as properties, either
>> single-valued for scalars, or multi-valued for lists. Files and  
>> images
>> properties are stored in Binary properties. XXX Because we want to be
>> able to load quickly "small" properties, we have to find a convention
>> for "big" String properties, to avoid loading them greedily from  
>> Zope.
>
>
> In JackRabbit only some BINARY values are loaded in memory only when
> needed - and they are stored in a file or in a resource on a virtual
> file system
> (the class used to shandle them is
> org.apache.jackrabbit.core.value.BLOBFileValue)
> BLOBFileValue provides a method getLength() that return the length
> without reading the file content
> But BLOBFileValue is internal to Jackrabbit ... I don't know if we can
> use it from outside

We can load the Value without loading the full blob, and the Value  
implementation for Binary does the correct thing with getLength(), it  
doesn't read all the file.

> If you use a STRING value and want to get it's length you need to load
> the string in memory.

Yes. But actually we shouldn't store anything big in strings.
JackRabbit's full text indexer gets data from Binaries and even  
though I'm not exactly sure how the SearchIndexes are configured, I'm  
confident we can do what we want with them.

So, Strings are only for shortish strings.

>> XXX How to deal with folderish documents...
>
>
> May be using a mixin type that adds the capability to the target  
> node to
> contain other documents.
> Example: Folder and Folderish nodes will share a mixin type let say
> "cps:folder"
> Another way is to use multiple inheritance of node types - but I don't
> know if it is supported by Jackrabbit
> Example: Folder and Folderish nodes will be derived from the same
> primary type let say "cps:folder"

Actually I was concerned about how to do the versioning for them. I  
guess folderish documents need to have children whose  
jcr:onParentVersion is COPY. So we need a different type for the  
children.


>> A proxy node has a special node type, and a single property of type
>> Reference pointing to the UUID of a nt:version in the version storage
>> space. (XXX check that this works ok in Jackrabbit.) This therefore
>> points to a precise version of a document.
>
>
> I think this it's supported by Jackrabbit. We will check this.
> Personally I prefer this solution as the impl. for the proxies ... it
> seems cleaner than the other option.

Yep.

Thanks for the comments.

Florent

-- 
Florent Guillaume, Nuxeo (Paris, France)   Director of R&D
+33 1 40 33 71 59   http://nuxeo.com   fg at nuxeo.com