nlight-jdev / jcouchdb

Automatically exported from code.google.com/p/jcouchdb
Other
0 stars 0 forks source link

Can't deserialize largish values of Long/long types, they end up being zero #44

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. Properties of type java.lang.Long do not reconstitute with the values
are large.

I have attached a test program that illustrates that Integer and Doubles
with .MAX_VALUE will serialize and deserialize correctly. Long will not.
This happens with largish numbers like System.currentMilliseconds() and
Date.getTime() produce. It saves them correctly, but will not load them
back correctly.

What is the expected output? What do you see instead?

the expected behavior is to correctly deserialize Long values.

What version of the product are you using? On what operating system?
jcouchdb = 0.10.0-3
svenson = 1.3.6

Please provide any additional information below.

import org.jcouchdb.db.Database;
import org.jcouchdb.db.Server;
import org.jcouchdb.db.ServerImpl;
import org.jcouchdb.document.BaseDocument;
import org.svenson.JSONProperty;

public class TransferCentral
{
    public static void main(final String[] args)
    {
        final Server s = new ServerImpl("localhost");
        s.createDatabase("testdb");
        final Database db = new Database("localhost", "testdb");

        final TestPojo tp = new TestPojo();
        tp.setId("testpojo");
        db.createDocument(tp);
        final TestPojo tp2 = db.getDocument(TestPojo.class, "testpojo");
        System.out.println(tp2);
        db.delete(tp2);
        s.deleteDatabase("testdb");
        System.exit(0);
    }

    public static class TestPojo extends BaseDocument
    {
        private Integer i = Integer.MAX_VALUE;
        private Long l = Long.MAX_VALUE;
        private Double d = Double.MAX_VALUE;

        @JSONProperty(value = "myint")
        public Integer getI()
        {
            return i;
        }

        public void setI(final Integer i)
        {
            this.i = i;
        }

        @JSONProperty(value = "mylong")
        public Long getL()
        {
            return l;
        }

        public void setL(final Long l)
        {
            this.l = l;
        }

        @JSONProperty(value = "mydouble")
        public Double getD()
        {
            return d;
        }

        public void setD(final Double d)
        {
            this.d = d;
        }

        @Override
        public String toString()
        {
            final StringBuilder sb = new StringBuilder();
            sb.append("TestPojo");
            sb.append("{i=").append(i);
            sb.append(", l=").append(l);
            sb.append(", d=").append(d);
            sb.append('}');
            return sb.toString();
        }
    }
}

Original issue reported on code.google.com by jarrod.r...@gmail.com on 14 Apr 2010 at 11:23

GoogleCodeExporter commented 8 years ago
[deleted comment]
GoogleCodeExporter commented 8 years ago
the problem is inside svenson JSONTokenizer here is a link to an issue in that
project and a patch file that fixes some of the problems. The main problem is 
large
Long values like Long.MAX_VALUE get serialized incorrectly, in the case of
Long.MAX_VALUE, 103 is being added to the value and then svenson is adding .0 
to the
end which causes svenson to convert it to a Double instead of a Long. Here is 
the
link to the patch.

http://code.google.com/p/svenson/issues/detail?id=14

Original comment by jarrod.r...@gmail.com on 15 Apr 2010 at 10:35

GoogleCodeExporter commented 8 years ago
Actually after more patching and testing, I found that Long.MAX_VALUE is getting
serialized to the wrong value, it is getting 103 added to it some how when it 
gets
written to CouchDB, that causes the overflow inside of svenson. I send in
9223372036854775807 Long.MAX_VALUE in Java
and 9223372036854776000 is what gets stored in the document. 

Original comment by jarrod.r...@gmail.com on 19 Apr 2010 at 11:45

GoogleCodeExporter commented 8 years ago
I submitted this bug to the couchdb team. 
https://issues.apache.org/jira/browse/COUCHDB-749

Original comment by jarrod.r...@gmail.com on 23 Apr 2010 at 5:27