You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The communication between the device and the desktop side is done by sockets. before it's sent over (both ways), the data has to be serialized. The serialization process modifies the objects and erases some of the information.
For example, the Realm.UUID type is converted to a string, and inner realm objects (the ones with property { type: 'object', objectType: '...' }) lose all the functions, connecting them to existing schemas (objectSchema function).
This problem has consequences, that can be split into two parts:
Mixed types
When mixed values belonging to Realm are sent over, the real type is lost. There is no difference between UUID('aa79b9ed-fbc0-4038-8f16-31f4da3efb9e') and string 'aa79b9ed-fbc0-4038-8f16-31f4da3efb9e'. The same problem happens when we assign linked objects to mixed properties. There is no way to find out to which schema the object belongs, since the objectSchema function is lost.
When sending that object between the device and the desktop, all the properties can be correctly converted upon receiving, since we can retrieve their correct type from the properties object. Also, containers can be properly handled.
Current solution
Right now non-mixed type conversion is only done when receiving the data on the device, in realm-flipper-plugin-device/src/ConvertFunctions.tsx file. That way of doing things is not perfect, since it only works for non-mixed types when the type is saved outside of the object being transferred.
My opinion on the ideal solution
Ideally, the properties of all the objects before sending via sockets should be wrapped with a type description (potentially like in MongoDB extended JSON).
This works nicely because this can save all the information about a value before it is serialized. Then, when receiving an object, it can be decoded and converted to a valid type. This would also work for con trivially serializable values in mixed properties.
The previously mentioned library (extended JSON) could be used, but with minor improvements:
data has to be handled properly
UUID seems to be not supported
on the desktop side: objects have to be kept together with their schema at all times
The text was updated successfully, but these errors were encountered:
The problem
The communication between the device and the desktop side is done by sockets. before it's sent over (both ways), the data has to be serialized. The serialization process modifies the objects and erases some of the information.
For example, the Realm.UUID type is converted to a string, and inner realm objects (the ones with property { type: 'object', objectType: '...' }) lose all the functions, connecting them to existing schemas (
objectSchema
function).This problem has consequences, that can be split into two parts:
Mixed types
When mixed values belonging to Realm are sent over, the real type is lost. There is no difference between UUID('aa79b9ed-fbc0-4038-8f16-31f4da3efb9e') and string 'aa79b9ed-fbc0-4038-8f16-31f4da3efb9e'. The same problem happens when we assign linked objects to mixed properties. There is no way to find out to which schema the object belongs, since the
objectSchema
function is lost.Non-mixed type erasure
Consider a simple schema:
When sending that object between the device and the desktop, all the properties can be correctly converted upon receiving, since we can retrieve their correct type from the properties object. Also, containers can be properly handled.
Current solution
Right now non-mixed type conversion is only done when receiving the data on the device, in
realm-flipper-plugin-device/src/ConvertFunctions.tsx
file. That way of doing things is not perfect, since it only works for non-mixed types when the type is saved outside of the object being transferred.My opinion on the ideal solution
Ideally, the properties of all the objects before sending via sockets should be wrapped with a type description (potentially like in MongoDB extended JSON).
This works nicely because this can save all the information about a value before it is serialized. Then, when receiving an object, it can be decoded and converted to a valid type. This would also work for con trivially serializable values in mixed properties.
The previously mentioned library (extended JSON) could be used, but with minor improvements:
The text was updated successfully, but these errors were encountered: