AW: Avoid binary streaming

["Cech. Ulrich" <Ul...@aeb.de>]

Hi Alex,

< Breaking the JCR API abstraction by getting to the datastore file directly is not a good idea.>

That's basically correct, but sometimes, it is important to have the file directly. In combination with some long-life hardware storage systems, it is necessary to change the file attribute and/or the "lastmodified"...


Bye,
Ulrich

Re: Avoid binary streaming

[Alexander Klimetschek <ak...@adobe.com>]

On 28.11.2012, at 18:01, Seidel. Robert <Ro...@aeb.de> wrote:

> For this specific file system (http://www.fast-lta.de/en/) , it is necessary to set the lastmodified date of the file to a date in the future, how long this file should be protected from deletion,

That seems like an awkward requirement - it obviously breaks the lastmodified semantic for files. Isn't there another option?

For example, the data store garbage collection relies on the lastmodified of files in the FileDataStore.

> this depends in our case dynamically on the data (can't be set fix to 6 years or so).

You know that the datastore only applies to binaries, and all other JCR data (node hierarchy and properties) are stored via the persistence manager and (depending on the implementation) usually in a database where all data is together in a few files on the file system. If those db files are lost (because the protection ran out or something) than you won't be able to get to the binaries in the datastore anymore (or at least no longer no their filenames and other metadata).

Cheers,
Alex

AW: Avoid binary streaming

["Seidel. Robert" <Ro...@aeb.de>]

Hello Alex,

For this specific file system (http://www.fast-lta.de/en/) , it is necessary to set the lastmodified date of the file to a date in the future, how long this file should be protected from deletion, this depends in our case dynamically on the data (can't be set fix to 6 years or so). 

The data store interface provides just two methods (which is a very good thing to integrate newer sub systems). One to store a stream and return an id and another to receive a stream with a given id. So the data store implementation just lacks of the necessary information to handle this problem itself.

Modifying the stream (write a header for example) would result in parsing problems at full text indexing, besides every access to and from the data store had to handle this header, so this was no solution at all.

Regards Robert

-----Ursprüngliche Nachricht-----
Von: Alexander Klimetschek [mailto:aklimets@adobe.com] 
Gesendet: Mittwoch, 28. November 2012 17:34
An: users@jackrabbit.apache.org
Betreff: Re: Avoid binary streaming

On 28.11.2012, at 12:10, Cech. Ulrich <Ul...@aeb.de> wrote:

> That's basically correct, but sometimes, it is important to have the file directly. In combination with some long-life hardware storage systems, it is necessary to change the file attribute and/or the "lastmodified"...

I don't know exactly what you mean... generally speaking, managing its files is the task of the persistence layer in Jackrabbit, i.e. the datastore implementation, and not the application level above the JCR API.

Cheers,
Alex

Re: Avoid binary streaming

[Alexander Klimetschek <ak...@adobe.com>]

On 28.11.2012, at 12:10, Cech. Ulrich <Ul...@aeb.de> wrote:

> That's basically correct, but sometimes, it is important to have the file directly. In combination with some long-life hardware storage systems, it is necessary to change the file attribute and/or the "lastmodified"...

I don't know exactly what you mean... generally speaking, managing its files is the task of the persistence layer in Jackrabbit, i.e. the datastore implementation, and not the application level above the JCR API.

Cheers,
Alex