[
http://jira.nuxeo.org/browse/NXP-3637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=55812#action_55812
]
Anahide Tchertchian commented on NXP-3637:
------------------------------------------
http://hg.nuxeo.org/nuxeo/nuxeo-core/rev/f7b61cdc1729
http://hg.nuxeo.org/nuxeo/nuxeo-services/rev/59acc2c8af22
first implementation done.
It is currently not possible to get the uri when reading the property. It is
not neither possible to set one of the blob properties independantly (need to
set the whole map of values directly) => this is a problem for setting the blob
length or mimetype for instance.
+ Does not work inside complex lists (because sub properties are resolved, so
the api ends up setting a blob instead of a map, and the blob does not hold the
uri information).
As a general note, the property model is really painful to use, because of the
different property notions we have, because of the lack of javadoc and because
the api does not fit the need of mapping an object to the storage.
> ExternalBlobs
> -------------
>
> Key: NXP-3637
> URL: http://jira.nuxeo.org/browse/NXP-3637
> Project: Nuxeo Enterprise Platform
> Issue Type: New Feature
> Components: Core
> Reporter: Thierry Delprat
> Assignee: Anahide Tchertchian
> Priority: Major
> Fix For: 5.2.1
>
> Original Estimate: 1 week
> Remaining Estimate: 1 week
>
> Nuxeo Core should be able to manage blobs that are physically stored in a
> external filesystem.
> At low level, this means we have to store a simple URL (or path).
> From API, blobs stored in Nuxeo and blob stored externaly should behave in
> the same way for reading.
> For update, we probably should have a ExternalBlob object.
> Use case
> --------
> It's possible to reference blobs using a new field nxs:externalContent,
> blobs will not be stored in the repository, but on the file system.
> API is transparent for this kind of document (getPropertyValue retrieves a
> blob), and it does not impact indexing (blob content will be indexed too).
> It should work in complex properties too (list of external blobs, complex
> prop or list of complex props holding an external blob).
> Technical Architecture
> ----------------------
> The string stored on the property kept in the repo is a uri that looks like:
> protocol://namespace/for/this/field/localname
> for instance we could have:
> protocol://nuxeo/externalBlob/myfiles/myfile.jpg.
> The namespace (here http://namespace/for/this/field/) is registered to the
> type service as the namespace for the field used on a given schema
> property. This can be useful to get the logic to retrieve the file.
> For instance, a namespace can be tied to a filesystem retrieval mechanism,
> where the folder containing the data is configurable. The rest of the URI
> (here localname) can be in this case the relative path to the file under the
> container folder.
> For instance we would have something like:
> <extension target="org.nuxeo.ecm.core.schema.TypeService"
> point="externalContent">
> <property name="myschema:myExternalStringProperty"
> namespace="http://nuxeo/fileSystem/externalBlob/fileSystem"; />
> <adapter namespace="http://nuxeo/fileSystem/externalBlob/fileSystem";
> class="org.nuxeo.ecm.core.adapters.FileSystemExternalBlobAdapter">
> <property name="container">/path/to/container/folder/</property>
> </adapter>
> <extension>
> The FileSystemExternalBlobAdapter class will follow an interface with the
> following API (ExternalBlobAdapter):
> - String getNamespace();
> - void setNamespace(String namespace);
> - String getUri(Serializable object, Map<String, Serializable> context)
> throws PropertyException;
> - Blob getBlob(String uri, Map<String, Serializable> context)
> throws PropertyException;
> In this class case:
> - the method getBlob should retrieve the file placed at
> /path/to/container/folder/relative/path/to/file, with path/to/file parsed
> from uri (keep the end of the uri as relative path). It should throw an
> exception if no file is found at this path.
> - the method getString should build the uri for a java.io.File passed as
> argument. If the object is not a java.io.File object, throw an
> exception. If the file absolute path does not start with the container
> folder path, throw an exception. Else build the uri with namespace +
> relative path.
> The adapter classes will be queried from the document properties api to
> retrieve a blob. Set apis do not have to be implemented for now (no set).
> Add on SchemaManager the following api:
> - ExternalBlobAdapter getExternalBlobAdapter(String fieldName)
> It should lookup the configuration to find the appropriate adapter.
> This API will be called from document properties. Grepping code using
> TypeConstants.CONTENT is a good start to take example on it and adapt blob
> mpanagement to the external blob.
> + need to check the blob extractor behaviour for indexing (it may need to be
> adapted to work correctly in this case).
> Problems
> --------
> - Do we have specific problems to deal with in case of multi-machine
> environment? no, it's coded on CoreSession side => it'll be on the core
> machine.
> - Do we harcode the field adapter mechanism like for nxs:content? => yes
> - Edit use case is not needed and more complicated (do we delete the old
> file, do we update the path or just update the content/or the content of
> the field, what happens on concurrent update of the same file) => just
> forget about it for now.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.nuxeo.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
ECM-tickets mailing list
[email protected]
http://lists.nuxeo.com/mailman/listinfo/ecm-tickets
