jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <mdue...@apache.org>
Subject Re: Encoding of JCR values in json
Date Fri, 13 Apr 2012 12:24:06 GMT

On 13.4.12 12:43, Jukka Zitting wrote:

>>> * The explicit encoding of numeric constants from JCR seems a bit
>>> troublesome and makes potential extensions more cumbersome.
>> What extensions come to mind?
> For example some applications might well want to be able to store
> things like coordinates (think of geospatial search) as individual
> scalars instead of collections of properties. Or there might be a
> desire to have a custom property type for say email addresses or phone
> numbers just like we have one for URLs in JCR 2.0. Or there could be a
> need for storing date and time values separately instead of the
> current timestamp values used in JCR. We don't have a current need for
> things like these, but a future JCR version or another standard or use
> case we want to support might well change that. Having an extensible
> typing mechanism makes implementing such things easy.

Makes sense. If we get rid of the explicit encoding using the numerical 
constants from PropertyType and use a more open approach we should be 
fine extension wise however.


>> The trouble with that is, that type info and value are spread across
>> different properties. Setting a JCR property requires two JSON diff
>> operations here.
> I don't think that would be too troublesome since the standard string
> and number formats cover the majority of properties.
>> Worse for JCR observation: the corresponding set property entries
>> might be spread across the journal.
> I'm not sure I follow. You mean a case where the value is set in one
> revision and the type in another? That should be interpreted as two
> setProperty() operations, each with different value types.

What I meant is: creating the JCR observation events from the 
Microkernel journal might be troublesome since the two setProperty 
operations (one for the value and the other for the type) are not 
guaranteed to be anywhere close to each other in the journal.

>> So there are three different approaches now: 1) encoding the type into the
>> value, 2) encoding it into a separate property, or 3) encoding it into the
>> name of the property.
> Microsoft chose a fairly smart variant of 1 for ASP.NET, see
> http://weblogs.asp.net/bleroy/archive/2008/01/18/dates-and-json.aspx
> For us that would mean something like this:
>      "example":{
>        "long":123,
>        "another long":"\/Long(124)",
>        "double":"\/Double(123.4)",
>        "string":"foo",
>        "another string":"/string"
>      }
> The only trouble is that for this to work we need to require the
> MicroKernel to keep track of the exact character sequences instead of
> just the logical, unescaped strings. Currently this indeed is the
> case.

Tom brought that up earlier already. I'm a bit sceptic about using a 
loop hole in the spec since clients using standard JSON parsers might 
not be able to distinguish between the long value

   "a long":"\/Long(124)"

and the string value

   "a string":"/Long(124)"

because in both cases they only see the un-escaped value which is the same.

Nevertheless the more I think about it, the more I'm convinced that the 
type should go together with the value. One reason is that the names are 
much more often accessed than the values and that the type mostly 
matters when accessing the value, not the name.

What about using three character prefixes to denote the type? That 
should give us plenty of type designators while parsing would still be 
very easy and fast.

     "another long":"lng:124",
     "another string":"str:xyz:string"

The type designators could then be registered/reserved somewhere (e.g. 
in the system workspace):

designator: lng
jcr-property-type: Long
jcr-property-type-code: 3


> BR,
> Jukka Zitting

View raw message