[infinispan-issues] [JBoss JIRA] Commented: (ISPN-1103) Soft schema-based storage
Randall Hauch (JIRA)
jira-events at lists.jboss.org
Fri May 13 10:16:50 EDT 2011
[ https://issues.jboss.org/browse/ISPN-1103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12601958#comment-12601958 ]
Randall Hauch commented on ISPN-1103:
-------------------------------------
I completely agree that storing metadata as a JSON structure is a brilliant approach. I've added several features the list in the description.
Storing the jsonObject as a string might work, especially if it is simply loaded and stored as an atomic unit. However, there are several advantages to storing it in a BSON (or BSON-like) representation, and all boil down to the fact that any schema-aware service will need to access the document contents for indexing, validation, computing differences (for DeltaAware functionality), and even applying changes (e.g., something similar to MongoDB's [atomic operations|http://www.mongodb.org/display/DOCS/Atomic+Operations]). Using a BSON representation will also make it more natural to handle binary values within the document.
Now, if we did store the document internally as BSON, we actually don't need to store the metadata separately. For example, we can store a single document with this structure:
{code}
{
"document" : /* user's document */
"metadata" : {
"schema-ref" : blah-blah
...
}
{code}
If represented as BSON, then the user's document is actually a nested BSON object stored under the "document" property name. This approach means that all the differencing, atomic operations, serialization, etc. functionality will work without having to distinguish between a user's document and a system metadata document.
> Soft schema-based storage
> -------------------------
>
> Key: ISPN-1103
> URL: https://issues.jboss.org/browse/ISPN-1103
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core API
> Reporter: Manik Surtani
> Assignee: Manik Surtani
> Fix For: 5.1.0.BETA1, 5.1.0.Final
>
>
> This JIRA is about storing metadata alongside values. Perhaps encapsulating values as SchematicValues, which could be described as:
> {code}
> class SchematicValue {
> String jsonMetadata;
> String jsonObject;
> }
> {code}
> Metadata would allow for a few interesting features:
> * Extracting of lifespan and timestamp data if manipulated over a remote protocol (REST, HotRod, etc)
> * Content type for REST responses
> * Timestamps for REST headers, will affect HTTP content caches
> * Validation information (may not be processed by Infinispan, but can be used by client libs)
> * Classloader/marshaller/classdef version info
> * General structure of the information stored
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the infinispan-issues
mailing list