jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Mueller <muel...@adobe.com>
Subject Re: Encoding of JCR values in json
Date Fri, 13 Apr 2012 13:40:50 GMT

>>An alternative might be: numbers with an "e" are double ("10e0"), numbers
>> with a dot are decimal ("10.0"), all other numbers are long ("10"). But
>> that would require the MicroKernel stores the *exact* JSON
>> I don't think that's a good idea either.
>The underlying storage mechanism must not be of concern to the user of
>the Microkernel API. The Microkernel API uses JSON to transport values.
>So the Microkernel implementation is in charge of serializing these into
>a format suitable for the underlying storage mechanism. Even if I put a
>number with 10 Million digits into a JSON property.

I think we should not rely on the MicroKernel implementation to support
unlimited precision numbers. For example MongoDB only supports IEEE 754
floating point numbers, as defined by the BSON spec:
http://en.wikipedia.org/wiki/BSON - so we can't store BigDecimal as a JSON
number, because we would risk losing precision.

Also, I would not rely on the MicroKernel implementation to preserve the
exact JSON representation. If we store the number as 100.00, we should not
rely on getting 100.00 back. We might as well get 100.0 or 100 back.

We should document this in the MicroKernel specification. The JSON
specification itself doesn't define such details.

>How could the GC possible know whether a
>binary is still in use or not?
>String blobId = mk.write(inStream);
>and write the returned blobId on a piece of paper. According to the
>current Microkernel contract I could come back after a couple of years
>and would still be able to retrieve that blob.

Yes, we need to narrow the contract.


View raw message