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 15:25:20 GMT

On 13.4.12 14:40, Thomas Mueller wrote:
> Hi,
>>> 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
>>> representation.
>>> 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.

And this should be done rather sooner than later.

>> 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.

Again, we'd rather be quick here.


> Regards,
> Thomas

View raw message