[
http://jira.nuxeo.org/browse/NXP-3637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anahide Tchertchian updated NXP-3637:
-------------------------------------
Description:
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.
was:
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.
> 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: Thierry Delprat
> Priority: Major
> Fix For: 5.2.1
>
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> 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
