Exclude empty or zero values (or null) from serialize

BIZ TMS XData
1

Hi,
for better optimization, there is a property or a parameter in Xdata for exclude properties with empty values, zeros and null in Xdata?
Thanks in advance

2

For serialization of PODO DTO objects, you can use JsonInclude attribute:

[JsonInclude(TInclusionMode.NonDefault)]
TDTOAddress = class
private
  {...}

The attribute can be applied for the whole class or for specific properties or fields. For entities, that is not possible.

3

HI Wagner,
I really meant entities.
There are entities that have 90% of the properties empty in Json result and the json grows exponentially, while it can be optimized for transport. (Clearly knowing the data structure in advance). Is there any intention to improve it?
Thanks

4

Entities are a little bit trickier because they involve direct (and automatic) database access. An empty string or zero value is different than a null value. Probably we could only do that for actually null values (not default) which might not decrease the size too much. It's something we can consider, but in the top list of priority right now. Is it causing you real issues?

5

Many tax management entities have up to 200 fields; most of the time only 30% of them are valued, depending on the cases. So many fields to zero (if numeric), empty (if strings) or to null (almost never, I always prefer to value everything).
The power of json is also in optimizing the data to be serialized.
Compared to other tools I get json to carry which are 4 times more voluminous and above all with more consumption of time and bandwidth (in fact the response is necessarily slower).
An option to not transmit zero numbers or empty strings as well as null fields, would allow in this case to get twice the speed in response (in TMSwebcore) and a smaller json to carry.
I ask for it as an optional setting, many can benefit from improving performance.
It is obvious that in this scenario I have to set the values ​​that will not be transmitted as empty by default in advance on the clientdataset.
Benefit: Direct driver for PostgresQL and Oracle? Planned?

6

It's something we can consider for a future release, that's for sure. Just note that for now you can use service operations and create your own DTOs, maybe for the critical entities, and you can move forward with no problem.

Direct drivers for PostgreSQL is planned, yes. For Oracle, no, at least not in near future.

7

Ok, Wagner.
Using my own DTOs does not allow to exploit the automatisms of the entities in Xdata, canceling or almost nullifying its advantage in the drafting of the code (except in special cases, of course).
I already use Sparkle with customized services that carry optimized json via JsonWriter, but I would like to get the maximum performance and resource savings via Xdata as well.
I hope to see this optimization soon, which could be activated on request (for example not when it is necessary to describe the structure of the entity, but only when I perform a GET for a Select).
All this with a view to achieving and exceeding the performances of competitors (our) who use, for example, NodeJs and other Javascript tools, that can manage thousands of connected users (which remains my goal).
As for PostgreSQL, direct access: welcome as soon as possible :slight_smile:
Thanks

8

Well, note that we keep improving service operations constantly, it's the first class way to use XData. Recently we added XData query support which makes it very easy to use XData queries in a service operation.

But yes, this optimization is interesting and we will implement that, nevertheless.

1 Like
9

Yes, this is an interesting feature, I've actually implemented myself a XData mod for that (along other stuff).

1 Like