search

mendix / RestServices

REST service module for Mendix. Supports consuming and publishing REST based services and real-time data synchronization. Supports JSON, form-encoded, multipart and binary data transport.
Apache License 2.0
31 stars 46 forks source link

Order of reference sets of NPE is discarded at serializing objects to JSON. #65

Closed ArjenLammers closed 8 years ago

ArjenLammers commented 9 years ago

As stated in commit https://github.com/mendix/RestServices/commit/77c588e26e2e0806f9fb71c5b454a5d4a21e0dea referencce sets are being sorted based on ID when retrieved. In some cases the order matters when composing a JSON. In this case we create a list containing several specializations and by sorting on ID, this order gets lost. This way, consuming a REST service where order matters and speciazliations are required lead to unexpected results.

It would be good to have some robust way of handling this.

mweststrate commented 9 years ago

Hi @ArjenLammers,

as the names of referencesets already suggests, ordering is not guaranteed in any form, so the best we can do here is to order on id during serialization. But if you order your source data first as desired, and then create fresh transient objects during your export you should be fine.

Mcpoowl commented 8 years ago

Hi @mweststrate,

As mentioned in https://mxforum.mendix.com/questions/9385/Google-Charts-JSON-wrongly-sorted, we've had some issues with sorting and the use of inheritence when using the Google Charts module from the app store.

Is there a robust workaround for this to work. Currently we've been altering the domain model to not make use of inheritence, but as you can imagine we'd like the model as clean as possible.

Any news regarding this issue? Or is this simply something that cannot be solved in a clean way?

mweststrate commented 8 years ago

Hi Paul,

There is no clean solution. However the referencesets are ordered by id on export by the Rest module, that means if you use non-persistent objects, they should be exported in the order you created them (based on id). However, part of the id encodes the type of the object afaik, and the rest of the id is only unique with a certain type (so effectively you have CAR-1, CAR-2, TRUCK-1, TRUCK-2 etc). So when having different types in the same set this will be an issue indeed. The only alternative I could think is to use created timestamps, but those could theoretically collide so that is an dangerous approach as well. So for now I don't see a clear workaround for this, maybe yet another magic attribute, like __json_orderid could provide an alternative for sorting by id.