[
http://jira.nuxeo.org/browse/NXP-3637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=55855#action_55855
]
Anahide Tchertchian commented on NXP-3637:
------------------------------------------
http://hg.nuxeo.org/nuxeo/nuxeo-core/rev/d05e1130b11b
> 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
