Java types to use for field type in server side code

[jay.l.fisher]

Using SmartGWT EE. Is it always the case that fields with type="integer" are Longs in the criteria, values and oldValues maps in the DSRequest the server sees? And does type="float" always result in a BigDecimal? I assume type="date" is always java.sql.date or java.util.date? If this is covered in documentation somewhere please point me to it. Thanks.

I want to be sure we write our server side code in such a way that we don't end up with problems if we move some tables to a different RDBMS.

[Isomorphic]

integers are represented as Longs by default, and floats are Doubles (not BigDecimal), dates are java.lang.Date or java.sql.Date (which is a subclass) if retrieved from SQL.

None of these will vary by RDBMS (or even DataSource type, like SQL vs Hibernate vs JPA).

[nikolayo]

I know that GWT does not support BigDecimal out of the box but there are some workarounds, so let me ask just in case: is there a way to deal with BigDecimal fields in Smart GWT? This is the type typically used e.g. to represent monetary amounts, so it is important.

[nikolayo]

I looked once again through this forum and found several questions but so far - no comments from Isomorphic as to current vision and/or plans for support of BigDecimal. Isomorphic, would you please comment on this? Monetary amounts and related coefficients happen to be important in my target domain, so BigDecimal is important too. I could possibly live with Double too but previous experience tells me it would be a life full of minor annoyances :).

[Isomorphic]

This is not related to SmartGWT, it's a feature core GWT needs and appears to be planned - just Google "GWT BigDecimal".

[nikolayo]

Implementation of BigDecimal for GWT is available in a stand-alone project at http://code.google.com/p/gwt-math/. AFAIK it was supposed to be incorporated into GWT 2.1 but did not make it.

Adding an implementation of BigDecimal to core GWT though will not result automatically in support in SmartGWT and SmartGWT EE since core field types seem to be hard-coded at least on the server side (on the client side it may be possible to do something along the line of SimpleType). I was trying to understand what are your plans in that respect. Or am I missing something that would result in automatic support or allow for custom support once BigDecimal is added to core GWT?

Regards
Nikola

Regards
Nikolay

[ljnelson]

This is not related to SmartGWT, it's a feature core GWT needs and appears to be planned - just Google "GWT BigDecimal".

It appears this is in GWT: http://code.google.com/p/google-web-toolkit/issues/detail?id=1857

...or am I missing something? Any updates on this subject?

Happy holidays,
Laird

[jay.l.fisher]

I'm looking into this again and the object types are not as you described. In server side code, if I examine the DSResponse using Eclipse debug after doing a fetch I can see that the data is a List of Maps. The Map keys are the field name as Strings, but the Map values are a mix of mostly Integer and BigDecimal (for the numeric fields), but also Boolean for the type="boolean" fields. When are they Longs and Doubles?

[Isomorphic]

In a DSResponse derived from a SQL database, data will vary by RDBMS as previously mentioned. Inbound data from the client will always use maximum precision (eg Long for an integer field) if you are looking at it from eg a DMI. It's then downcast as needed as it hits the DataSource validation and persistence logic and actual field types are known.

As far as BigDecimal, you can support this now with a SimpleType with parse and format methods that keep the internal value as a String. This will mean it arrived at the server as a String, where you can parse it in a DMI or custom DataSource. We'll be adding this as a built-in field type in the future (no ETA yet).

[jay.l.fisher]

Earlier you said "None of these will vary by RDBMS (or even DataSource type, like SQL vs Hibernate vs JPA)."

So if it will vary by database type, how should server side code be written to consistently deal with values read from the database?

[Isomorphic]

Sorry, to clarify, inbound values will not differ by RDBMS or even persistence type. Values coming from an RDBMS are based on the underlying column type and your JDBC driver's behavior - we don't try to force them to a particular type.