[
http://jira.nuxeo.org/browse/NXP-3637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=55852#action_55852
]
Anahide Tchertchian commented on NXP-3637:
------------------------------------------
http://hg.nuxeo.org/nuxeo/nuxeo-core/rev/d24bf114adc5
changed implementation to not use the object adapters and setlle for a map.
this is working great until DocumentPart API is involved: when setting a
property value, it is resolved and the map (holding the uri) is lost. This is
happening also in lists and complex properties.
=> 2 options:
1. add uri getter and setter on the blob to make it hold the info
2. add a new method on properties that will return the value for edit.
Option 2 was taken as properties are not used much by the rest of the code, and
as an AbstractProperty class makes it possible to default it to the getValue()
method.
The new method is called getValueForWrite, it can be renamed if not appropriate.
> 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
