Inconsistent encoding of objects in a list #334
Comments
davvid
added a commit
to davvid/jsonpickle
that referenced
this issue
Jan 14, 2021
Previously the make_refs=False / unpicklable=False code path would avoid emitting data for objects it had already seen. It mostly did this to avoid cycles, as its reference system is disabled in these modes, and thus the result was that null was emitted for any objects that appear more than once in the object graph. Improve the behavior by keeping track of objects that we have already flattened and simply return the pre-flattened representation when we re-encounter the same object. This is a simple solution that fixes encoding of datetime objects with UTC tzinfo in these scenarios. Resolves jsonpickle#333 jsonpickle#334 jsonpickle#337 Signed-off-by: David Aguilar <davvid@gmail.com>
This was referenced Jan 14, 2021
|
Please test the proposed changes in #338 and let me know if it fixes things for your use case. |
davvid
added a commit
to davvid/jsonpickle
that referenced
this issue
Jan 14, 2021
Previously the make_refs=False / unpicklable=False code path would avoid emitting data for objects it had already seen. It mostly did this to avoid cycles, as its reference system is disabled in these modes. The end result was that null was emitted for any objects that appear more than once in the object graph. Improve the behavior by keeping track of objects that we have already flattened and return the pre-flattened representation when we re-encounter the same object. This is a simple solution that fixes encoding of datetime objects with UTC tzinfo in these scenarios. It also improves encoding of objects with multiple references to the same object as the object will now be properly encoded each time it is encountered in the object graph. Resolves jsonpickle#333 jsonpickle#334 jsonpickle#337 Signed-off-by: David Aguilar <davvid@gmail.com>
davvid
added a commit
to davvid/jsonpickle
that referenced
this issue
Jan 14, 2021
|
Now the encoding strategy is consistent, thanks! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
After the fourth object the encoding strategy differs - see Almenon/AREPL-backend#163
Is there a reason for this? I'm not sure if it's intentional or not.
The text was updated successfully, but these errors were encountered: