[Cps4] cps/jcr document mapping

[Bogdan Stefanescu]

Hi Florent,

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

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
If you use a STRING value and want to get it's length you need to load
the string in memory.

Anyway for special features we may contribute with extensions to jackrabbit


> 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"

> 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.


Bogdan


Florent Guillaume wrote:

> On 6 Apr 2006, at 15:37, Florent Guillaume wrote:
>
>> Could at least Bogdan and Eugen have a quick look at
>> https://svn.nuxeo.org/trac/priv/file/nuxeo.capsule/trunk/src/nuxeo/
>> capsule/doc/DOCUMENT-MAPPING.txt
>> and tell me what they think?
>
>
> Actually I think I'll already revisit the way Image and File are 
> stored, they need more than just a blob, so a type based on 
> mix:referenceable and nt:resource is probably the way to go. 
> mix:referenceable is needed for now because in my ZODB mapper I 
> expect all nodes to have a jcr:uuid.
>
> Florent
>
>
>> Especially in the context of Apogée using the same model.
>>
>> Others' comments are welcome too (you have to be familiar with 
>> JSR-170 though).
>>
>> Florent
>
>


-- 

Bogdan Stefanescu - Apogee project Team Leader

Nuxeo - Open Source ECM - www.nuxeo.com
Apogée - the rich client platform for ECM
http://apogee.nuxeo.org/ - http://www.nuxeo.com/en