jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexander Klimetschek" <aklim...@day.com>
Subject Re: Accessing DataIdentifier associated with binary property from DataStore
Date Thu, 03 Jul 2008 18:05:48 GMT
Hi Jerome,

you can easily provide a file system view of the repository through
the WebDAV interface. This way you will store everything inside JCR,
your old application will access the files through the WebDAV
interface (you can mount a webdav repository as a file system in all
modern OS) and the new application can leverage all JCR API features.

When installing the jackrabbit-webapp.war you will already have WebDAV
contained. The standard WebDAV view only presents nodes of type
nt:folder and nt:file, but you can extend that.

See also

http://jackrabbit.apache.org/jackrabbit-web-application.html
http://jackrabbit.apache.org/jackrabbit-jcr-server.html
http://jackrabbit.apache.org/jackrabbit-webdav-library.html
http://wiki.apache.org/jackrabbit/WebDAV

and search the mailing list for WebDAV (and "IOHandler" on how to
customize the WebDAV view).

Regards,
Alex

On Thu, Jul 3, 2008 at 7:49 PM, Jerome Banks <jerome.banks@gmail.com> wrote:
> Thomas,
>   Let me explain the use case a little more.  You  might think that it
> isn't what jackrabbit is intended for, but I can imagine a lot of users
> having similar requirements.
>
>   Basically, we have an application which accesses files from a
> filesystem.  This application is basically legacy, and cannot be altered to
> access files through jackrabbit. (At least no time soon)  What we would like
> is to be able to store binary files in a JCR repository, and have it
> immediately accessible from the legacy application (without having to worry
> about copying files and keeping JCR and the legacy filesystem in sync
> somehow).  We want to leverage Jackrabbit to store metadata, and have things
> like queries, indexing, etc.  Using a custom DataStore, we can keep it on
> the remote filesystem, so that it accessible from the legacy app. However,
> we have no way of communicating to our legacy app where a particular item is
> on the filesystem,  where a particular item is, because we can't translate
> between a Property, and the associated DataIdentifier on the DataStore.
>
>  I think the basic requirement is to have the notion of a "DataStore",
> which is a custom or legacy method of storing binary data, but isn't a full
> content repository.  It doesn't really make sense to implement a fullblown
> SPI, because all we're doing is "storing data".  There are cases, however,
> where we have a "leaky abstraction", and some part of the application needs
> to know exactly where in the DataStore a particular item is being stored.  I
> guess this is somewhat different from the current notion of "DataStore",
> which is a "optimization" tightly associated with BundlePersistenceManagers.
>
>
>  My current approach is to implement a custom PersistenceManager which
> delegates to another PersistenceManager implementation, but intercepts
> certain binary properties. It then would store the binary property in the
> DataStore, and store the DataIdentifier as a generated pseudo-property in
> the delegated PM.  My question was just if there was an easier way; if the
> delegated PM was known to be a BundlePersistenceManager, could we look up
> the DataIdentifier directly from a given Property. I guess not.
>
> -- jerome
>
> On Wed, Jul 2, 2008 at 11:01 AM, Thomas Müller <thomas.mueller@day.com>
> wrote:
>
>> Hi,
>>
>> Could you please explain what is the use case, that means why you want
>> to do that?
>>
>> >  I've gotten a custom DataStore implemented with the
>> > BundleDBPersistenceManager
>>
>> I am not sure if I understand - you wrote an adapter / wrapper package
>> that implements the DataStore interface and can use any
>> BundleDBPersistenceManager? This sounds very interesting. Do you plan
>> to provide the source code for that?
>>
>> > some part of my application needs to access the DataIdentifier associated
>> > with storing a particular binary property.
>>
>> Currently it works like this: when storing a binary property,
>> Jackrabbit first checks if the binary property is small (shorter than
>> some number of bytes, lets say 1 KB). If shorter, the data is stored.
>> If larger, then the binary is stored in the data store, and the unique
>> hash value is stored. The DataIdentifier is this hash value. So you
>> already have it.
>>
>> >  Basically, if I have a binary Property from a Node, can I look up the
>> > identifier based on the Property's UUID?
>>
>> Properties are not and have no UUID. The hash value is not really a
>> UUID (it looks like one but it is not).
>>
>> > The BundlePersistenceManager has to
>> > keep these stored somewhere, right?
>>
>> The hash values are persisted in the persistence manager. But I'm not
>> sure if this is the question. The BundlePersistenceManager persists
>> all data (it should ;-)
>>
>> Regards,
>> Thomas
>>
>



-- 
Alexander Klimetschek
alexander.klimetschek@day.com

Mime
View raw message