jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Seidel. Robert" <Robert.Sei...@aeb.de>
Subject AW: Avoid binary streaming
Date Wed, 28 Nov 2012 17:01:39 GMT
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 <Ulrich.Cech@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

Mime
View raw message