how to create a Criterion from a Long value?

[csillag]

Hi all,

I would like to create a Criterion for matching a long value, but (as of ver 2.4) the Criterion class does not seem to have any constructor for long.

How can I do that?

Thank you for your help:

Csillag

[csillag]

By the way, the Record class, which has specific getter and setter methods for several types (including Integer, Double, Float), also does not have any getAttributeAsLong(String) and a setAttribute(String, Long) method.

So, how should I get/set the long fields safely?

Thank you for explaining:

Csillag

[atomatom]

I believe you can use Integer without problems. Or, if you’re afraid of precision grab it as a string and then parse it to/from a long.

I noticed this a last week as well when I converted my IDs to longs.

[csillag]

@atomatom

I believe you can use Integer without problems.

Integers have a defined range. (They go from -2^31 to 2^31 - 1.)
There is nothing stopping me to define a field in SQL that goes beyond that, like, int(13).

In these cases, the Integer class clearly can not hold the values. However, the Long class could…

Thank you for your help:

Csillag

[atomatom]

Yeah, I was a bit worried about precision which is why I used the getAttributeAsString and then parsed it to a long.

Javascript has 64 bit numbers but I’m not clear how that interacts with GWT. This has some clues

http://code.google.com/webtoolkit/doc/latest/DevGuideCodingBasicsCompatibility.html

long: JavaScript has no 64-bit integral type, so long needs special consideration. Prior to GWT 1.5, the long type was was simply mapped to the integral range of a 64-bit JavaScript floating-point value, giving long variables an actual range less than the full 64 bits. As of GWT 1.5, long primitives are emulated as a pair of 32-bit integers, and work reliably over the entire 64-bit range. Overflow is emulated to match the expected behavior. There are a couple of caveats. Heavy use of long operations will have a performance impact due to the underlying emulation. Additionally, long primitives cannot be used in JSNI code because they are not a native JavaScript numeric type.

[csillag]

OK, so it’s not trivial to handle this on the SQL/JS/Java barriers, but still it’s a valid requirement to handle these values.

Handling them as String (and converting to/from Long on demand) would definitly work, but does one have to do this manually, in the app? It would be nice if this could go into SmartGWT…

Thank you for your help:

 Csillag

[atomatom]

My guess is this is an artifact of SmartClient being Javascript. So, the DataSourceField type actually is an Integer since a Long would do nothing different. I think you could still be bitten by a Long using the last few bits, and I recall seeing a post on that before.

It would be nice if Long was supported on the client side. Or if someone can clarify/test that GWT actually does not care if it is an Integer or a Long - my guess is that it does, I just did not have time to write the test for it yet.

[csillag]

The GWT docs (quoted by you) clearly says that GWT stores the Java long values in two JavaScript 32-bit integers, while the Java integer type is used natively.

So, there is definitly a difference.

* * *

I understand that in JavaScript (and thus in SmartClient) there is no way to support Long values natively, but in SmartGWT, we can to this, and when working with really long numbers, this can be necessary.

So, my decision still depends on Isomorphic’s take on this.

If they confirm that there is no specific support, I will go with the String route. But for this to work, I must be able to properly detect the range used by each field - about that, see this thread: http://forums.smartclient.com/showthread.php?t=15520

Thank you:

 Csillag

[Isomorphic]

We will be adding a Criterion constructor which takes a Long value.

This will (at least in the initial implementation) be converted to a JavaScript Number in the SmartGWT JSNI code (this is a 64-bit floating-point number, so has less precision than a Java long, but greater precision than Java Integer).

Isomorphic Software

[csillag]

Great!

Do you also plan to add the matching Record.getAttributeAsLong(String field) and setAttribute(String field, Long value) methods, too?

Thank you:

Csillag

[csillag]

@csillag

… add the matching Record.getAttributeAsLong(String field)

In my previous post, I wrote getAttributeAsInt. I have ment getAttributeAsLong.

[Isomorphic]

Yes those will be present too.
In fact this change should show up in the next nightly build.

[csillag]

@csillag

Integers have a defined range. (They go from -2^31 to 2^31 - 1.)
There is nothing stopping me to define a field in SQL that goes beyond that, like, int(13).

Just to correct the mis-information I wrote earlier: int(13) is still a simple SQL Integer type; the number suffix only influences formatting (if it is honored at all.) So, a MySQL field defined as “int(13)” can be stored in a Java Integer type.

However, “unsigned int” and “bigint” fields have a range that surpasses that of the Java Integer, but can be stored as Java Long. (And “unsigned bigint” is too big for even Long to hold.)

So, to wrap this up, Long support is definitly useful, but my original example was wrong.

[csillag]

@Isomorphic

We will be adding a Criterion constructor which takes a Long value.

This will (at least in the initial implementation) be converted to a JavaScript Number in the SmartGWT JSNI code (this is a 64-bit floating-point number, so has less precision than a Java long, but greater precision than Java Integer).

Isomorphic Software

Just for the record: the proposed implementation will be able to handle the SQL UNSIGNED INT type (which is too much for the Java Integer type), but will not be able to handle the SQL BIGINT type (which needs a real full Java Long implementation.)

So, to handle SQL BIGINT values, one still needs to read out the value from the record as String, and then manually convert it to Long, right?

[csillag]

@Isomorphic

Yes those will be present too.
In fact this change should show up in the next nightly build.

It’s working great with the feb. 17 nightly build.

Thank you.

[mathias]

Hi, looked into this as part of figuring out how to deal with the fact that i have Long as PK for all my serverside domain objects.

Isomorphic, even if i get “getvalueaslong()”-method, does this help the fact that the only datatype for the *.ds-fields are “integer”?

My question is how smartgwt handles the conversion from my serverside Long PK to what i get in the client, and then send back.