On 20/07/11 13:15, Laurent Pellegrino wrote:
Just to fix a mistake in my previous message : Long are 64 bits and not 128.
On Wed, Jul 20, 2011 at 2:02 PM, Laurent Pellegrino
<[email protected]> wrote:
Thanks for your explanations. However, my problem is that
node.getLiteralValue() on the node returns an Integer Java object.
DatasetGraphTDB dataset = TDBFactory.createDatasetGraph();
dataset.add(new Quad(
Node.createURI("http://openjena.org";),
Node.createURI("http://openjena.org";),
Node.createURI("http://openjena.org";), Node.createLiteral(
"-628675214", null, XSDDatatype.XSDlong)));
Iterator<Quad> res =
dataset.findNG(Node.ANY, Node.ANY, Node.ANY, Node.ANY);
Quad quad = null;
while (res.hasNext()) {
quad = res.next();
System.out.println(quad.getObject().getLiteralValue().getClass());
}
dataset.close();
It prints:
class java.lang.Integer
Or the problem is that I use quad.getObject().getLiteralValue() as a
parameter of a method that expects a Java Long object because the
value that was initially stored was a Long:
myMethod((Long) quad.getObject().getLiteralValue())
Or I get a ClassCastException due to the fact that
quad.getObject().getLiteralValue() returns an Integer.
because the value (-628675214) can be fitted into an Java Integer. It's
just a class choosen because it can represent the value. Ditto xsd:byte.
Indeed, it is not possible to store a full Long (128 bits) as a typed
literal (due to the fact that numbers are encoded into 56 bits).
If it does not fit in 56 bits, then TDB stores the thing in the long
form. 56 bits is not a limitation on the values that can be stored -
its the limit on what can be stored compactly. If it does not fit, TDB
falls back on storing the lexical form and type.
Hence, I have to store it as a non-typed literal and to parse it
manually but it also means that I cannot apply any method specific to
numbers on that field from a SPARQL query. That's why I was thinking
it is an issue :(
You should be able to
class Integer extends Number
Number.longValue()
What operation are you wishing to perform?
Andy
Laurent
On Wed, Jul 20, 2011 at 11:45 AM, Andy Seaborne
<[email protected]> wrote:
On 19/07/11 14:56, Laurent Pellegrino wrote:
Hi all,
I am currently using a TDB instance with Quadruples (DatasetGraphTDB).
I insert some quads with a literal value which is typed with xsd:long:
Node.createLiteral(Long.toString(myIdWhichIsAJavaLong), null,
XSDDatatype.XSDlong)
At this step if I print the content to the standard output I get something
like:
"1900023546"^^http://www.w3.org/2001/XMLSchema#long
Then, I execute a query that return the quadruples that contain the
literal values that were initially typed as xsd:long. When I print the
content to the standard output I get:
"1900023546"^^http://www.w3.org/2001/XMLSchema#integer
Why does the datatype is not the same? Is it an issue?
No - or at least, it shouldn't.
xsd:long is a XSD 64 bit number
xsd:integer is an arbitrary precision
xsd:integer is a more general datatype than xsd:long (xsd:int is the 32 bit
XSD integer).
TDB stores numbers (integers, decimals, doubles), and dates and dateTimes
and booleans, as their value, not as their lexical form. Actually, it
encodes them into 56 bits (currently). If the number does not fit it is
stores via the node table and lexical form.
This saves space and makes queries involving FILTERs on values go faster.
Much faster.
See NodeId.inline(Node)
Andy
