You could use:
myMethod(((Number)getLiteralValue()).longValue())
which will get auto-boxed to Long.
Andy
On 20/07/11 13:44, Laurent Pellegrino wrote:
Ok, the operation i am trying to perform is:
myMethod((Long) quad.getObject().getLiteralValue())
where the method signature is:
public void myMethod(Long value);
and where the initial value inserted as a typed literal was declared
as xsd:long.
One of the solution I have found is:
myMethod(Long.parseLong(quad.getObject().getLiteralLexicalForm()))
I have understood that Jena returns an Integer because the value fit
into a 32 bits value but the literal was created and tagged with a
xsd:Long (which is defined as a signed 64-bit integer) that's why I
expect to get a Java Long when I call
quad.getObject().getLiteralValue(). Even if the value can fit in a
Java Integer.
Laurent
On Wed, Jul 20, 2011 at 2:27 PM, Andy Seaborne
<[email protected]> wrote:
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
