jackrabbit-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Jackrabbit Wiki] Update of "Composite Blob Store Storage Filters" by MattRyan
Date Tue, 15 Aug 2017 21:27:51 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jackrabbit Wiki" for change notification.

The "Composite Blob Store Storage Filters" page has been changed by MattRyan:

Adds technical challenges section.

  When this situation is encountered, the composite blob store should also initiate an asynchronous
background job to move the blob from it's current location to the proper one - the location
where it would be found if it were being created now - on read requests, or for write requests
should write to the correct location and remove the blob asynchronously in the background
from the current location after the write is done.
+ === Technical Challenges ===
+ The Data Store API doesn't have knowledge about any JCR node information for the binary
being written, and doesn't have any provision to provide that information to any of the data
store APIs today.  The primary way a binary is created is to do so without any node information.
 Usually the node is created after the binary creation has taken place.  This means that,
while potentially useful, providing JCR information to the data store is problematic.
+ ==== Possible Solutions ====
+ NOTE:  (Matt Ryan): I don't fully understand the impacts of all suggestions here; additional
suggestions and feedback encouraged.
+  * '''Rework the API to support providing JCR information in data store calls.'''  While
I'm not 100% sure of this, I assume the JCR node information is at least known at the time
a binary is created; otherwise we wouldn't know whether it can be created, if there is already
something with the same name in the node store, if the user has rights to create at this location,
+  * '''Encode JCR information in the data identifier.'''  This could be possible and might
minimize public API contract changes.  However, not all calls are based on a data identifier
(e.g. DataStore::getRecordFromReference(), DataStore::addRecord()).  And doing this would
also probably imply upgrade challenges, as all existing blob IDs would have to be recreated
to contain the new encoded information.
+  * '''Allow the creation of blobs in one location, and let curation move them later if needed.'''
 This would mean that blobs would usually (always?) be created in a non-filtered delegate
first, and then (frequently or rarely, depending on filter configuration) would have to be
moved to a more optimal location later, once node information was known.  This could be done
via a background curation process or on-demand when the blob is first requested. 

View raw message