jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Re: Value types supported by the MicroKernel
Date Thu, 22 Mar 2012 15:22:46 GMT
Hi,

On Thu, Mar 22, 2012 at 3:04 PM, Stefan Guggisberg
<stefan.guggisberg@gmail.com> wrote:
> On Wed, Mar 21, 2012 at 8:26 PM, Jukka Zitting <jukka.zitting@gmail.com> wrote:
>> For oak-core (see OAK-33 [1]) we'd need a bit more detailed definition
>> of the supported value types. A few questions:
>
> the microkernel as currently implemented does not interpret property
> value types, it just stores the value token.

Can we turn that into a harder API contract, i.e. one that should hold
true for any MK implementation? If not, we need to define the
boundaries of what oak-core can expect the MK to store reliably. We
don't need the answers right away, but ultimately this needs to be
defined for us to properly resolve OAK-33.

A related question, will a value like "\u0058" be considered equal to
"X" for example when merging concurrent changes? What about [ ] vs. []
(i.e. extra whitespace within an empty array)?

>> 2) Are null values (the "null" keyword) supported? It would be nice if not.
>
> setting a property to null (e.g. ^"foo":null ) removes it (as in JCR).
>
> however, adding a node with null valued properties is currently possible.
> that should probably be fixed.

OK, sounds good. So oak-core can treat a case like {"foo":null} being
returned from MicroKernel.getNodes() as an unexpected error, probably
caused by an administrator directly accessing the MicroKernel.

>> 3) Are arrays (i.e. "[" ... "]") supported? If yes, are there
>> constraints on element types? It would be nice if arrays indeed were
>> supported. With the restriction that all elements are scalar values of
>> the same type.
>
> it does support arrays but doesn't enforce restrictions.
>
> the microkernel should IMO just support the basic json model.
> restrictions should be handled on a higher level.

OK, cool.

>> 4) Are there limits on number values? Most notably, can a number
>> that's larger than Long.MAX_VALUE be stored reliably (as a number)?
>> Larger than Double.MAX_VALUE? What about things like Double.NaN? Or
>> weirder, the other 2^51 NaN values allowed by IEEE754?
>
> whatever you pass in the commit is stored and returned as-is.
> as already mentioned, the value is (currently) not interpreted.

OK. Can we get rid of the "(currently)" qualifier? Also, the "not
interpreted" part needs to be qualified in terms of things like
conflict merging. I'd be fine with "store and used as an opaque,
unparsed character sequence".

Basically this means that in oak-core or -jcr we need to either a) not
support all possible Java double values or b) use some custom string
encoding for such values. I suppose a) is the better alternative, but
we need to check whether that will cause problems down the line.

>> 6) Presumably strings are in Unicode. Are characters beyond the BMP
>> supported? Is it possible for a string value to contain a Unicode
>> non-character, for example U+FFFF?
>
> erm, haven't thought about that. do you think that there could be a problem?

Like with the Double.NaN case, unless the underlying MicroKernel
supports the full range of characters, we need to consider adding some
extra level of encoding (possibly simply the \uNNNN escapes) on the
oak-core or -jcr level. But it sounds like this won't be needed.

BR,

Jukka Zitting

Mime
View raw message