-
Notifications
You must be signed in to change notification settings - Fork 93
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider switching to Poison #237
Comments
You are right. We have to switch to [devinus/poison]. Let me think about further steps towards Option A. Thanks. |
I like your proposal, but still thinking about that... |
@rschmukler It's a good idea, can you create some draft PR? |
+1 I've been dealing with cryptic encoding issues due to |
@mtwilliams How did you managed your issues with Tirexs and DateTime encoding ? |
@Electron-libre Manually lowered to ISO 8601. |
Thank you for your work on this library, it's fantastic!
It would be nice if this library used the more feature rich and maintained devinus/poison for HTTP encoding. It also claims to be among the fastest native JSON libraries.
The big advantage that this would allow is support for searches to decode directly into structs. I envision an API as follows:
Further benefits include the ability for those structs to be able to implement
Poison.Encoder
andPoison.Decoder
to allow customjson
representations.I looked into implementing this, and there is one major problem: Poison does not support encoding lists into objects. ie.
[{:_id, 5}]
is not currently supported. The existing code base has a heavy reliance on this feature.The options, if you are open to the switch, I see as follows:
HTTP.encode
to recursively convert lists into maps usingEnum.into/2
. This is a much easier fix to implement, but adds a performance overhead of recursively converting lists.To me, A seems the more "correct" approach, even though it is a good deal more work. Eager to hear your thoughts.
edit Upon further thought, the query objects are generally pretty small and sent relatively infrequently... Option A is probably a safer and cleaner approach
Thanks!
The text was updated successfully, but these errors were encountered: