latest 13.1 uses different java type for integer fields

[claudiobosticco]

Oracle 19c

Hello, I just noticed that with 13.1-d20230927 I get Long for integer fields, instead of BigDecimal.
I don't typically rely on this behavior in my code, so it was helpful to me to discover a point where I did it by mistake, but I wanted to mention it in case it's indicative of any issue, as that piece of code had already survived several versions of 13.0 and 13.1 unscathed.

[claudiobosticco]

actually I also noticed that a field defined as:

<field name="ID_RECS" type="text" includeFrom="AUTH_USERS.ID_REC" customSQL="true"/>

where the field which is included is of type integer, and is used in a summaryFunctions section:

<summaryFunctions>
                <ID_RECS>concat</ID_RECS>
</summaryFunctions>

this field results in a Long when is a single value, and a String when is actually a concat of multiple values.

[Isomorphic]

Hi Claudio, we are in the midst of implementing a major enhancement where we avoid the (somewhat expensive) re-fetch of a newly inserted record, for cache sync purposes (updating the browser's cache).

Unfortunately, JDBC drivers are super inconsistent here, in terms of what they return if we ask for PK values for a newly inserted record. Generally speaking, some return different types if you do a normal select vs ask for the newly inserted PK value. Looks like you must be using Oracle, which is the worst of the bunch in this area.

We're still figuring this out, thanks for the feedback on this. We'll let you know, here, when we feel like this is in final form. For now, it's a good idea to modify your code so it can handle various different numeric types.

[claudiobosticco]

thanks for the clarification, I forgot to say that I wasn't doing an add, but a fetch.

[Isomorphic]

#1 Regarding the issue with the add operation returning Long instead of BigDecimal, due to recent cache sync changes, this behavior is now expected. The default cache sync strategy, 'requestValuesPlusSequences,' does not perform a fetch to obtain return values; instead, it uses incoming values. This explains why you are receiving Long values. Please note that if you place BigDecimal into request.values, you will receive returned values as BigDecimal as well.

#2 Regarding the fetch operation returning String or Long based on the number of concatenated values, could you please provide more details? We were unable to reproduce this issue. For us, this field consistently returns a String, whether it contains a single value or multiple values.

[claudiobosticco]

SNAPSHOT_v13.1d_2023-10-29/Enterprise Deployment

Hello, actually with this version I don't see #2, it's fixed for me.

Regarding #1, thanks for the explanation, seems a nice improvement, but will it be a configurable behaviour?

[Isomorphic]

It is configurable - please search for "Automatic Cache Synchronization" in Smartclient 13.1 reference.