omitNullMapValuesInResponse working correct by default?

[Blama]

Hi Isomorphic,

the docs mention a default of false for RPCRequest.omitNullMapValuesInResponse, which I can also see in framework.properties.
On the other hand in the default Live Grid sample, the field nextShipment is empty for all rows.

If I now look in the Developer Console's RPC Tab, I don't see a nextShipment: null entry for all rows. But with the default of omitNullMapValuesInResponse:false it should be present, shouldn't it?
I'm asking because I'm using a integration tool with your RESTHandler and that tool does not empty "missing" fields in the target system.
It would empty them if the fetch returned nextShipment: null.

For daily use with the normal client of course the omitted entries are perfect.

Thank you & Best regards
Blama

[Isomorphic]

omitNullMapValuesInResponse will only have an effect if there are some null values in the Maps being processed.

There are no null values in the Maps in this instance, because they come from SQL, and for fields that have no value we do not put an explicit null into the Map.

[claudiobosticco]

maybe would be useful a note in the docs to clarify this, as in the past I've done the same incorrect assumption:
https://forums.smartclient.com/forum...luesinresponse

[Blama]

Hi Isomorphic,

I agree with claudiobosticco.

What would be even better: You already know which fields you request from the DB from the SELECT-field list you generate.
Any field not present in the result map is null then, right? I assume therefore a few lines of code you should be able to amend the nulls in SQLDataSource, right? (This refers to this answer of yours in the other thread)

omitNullMapValuesInResponse can then later decide what to do with these nulls.

Best regards
Blama

[Isomorphic]

The doc clarification makes sense, but adding explicit nulls for SQL results definitely could not be a new default behavior, as it’s mostly a waste of bandwidth.

Do you have a SQL-based use case where explicit nulls would be useful? Because the value received in JavaScript is undefined, which is treated as null in most cases, and SQL DBs do not, as a rule, have a separate notion of undefined vs null.

[Blama]

Hi Isomorphic,

yes, as I wrote above in #1.
I'm using an integration tool with RESTHandler and as of today, the tool does not sync perfectly.
Right now, empty fields in our system are not emptied in the target system, as there isn't a value sent.
It would empty them if the fetch returned fieldname: null.

For daily use with the normal SmartGWT-clientside of course the omitted entries are perfect, and as you write them being present there is a waste of bandwidth.

Perhaps it makes sense as setting like this:

• sqlGenerateNullValues: false (new setting in framework.properties)
• omitNullMapValuesInResponse: false (existing setting in framework.properties)
• sqlGenerateNullValues: true (property of DSRequest, set by the integration tool)

or:

• sqlGenerateNullValuesIDACall: false (new setting in framework.properties)
• sqlGenerateNullValuesRESTHandler: true (new setting in framework.properties)
• omitNullMapValuesInResponse: false (existing setting in framework.properties)

Best regards
Blama

[Isomorphic]

We don’t plan to add such settings, though if critical for you it would be a valid Feature Sponsorship.

If you need nulls, we would recommend adding them in a DMI.