Skip to content
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

Open
rschmukler opened this issue Jul 27, 2016 · 6 comments
Open

Consider switching to Poison #237

rschmukler opened this issue Jul 27, 2016 · 6 comments
Labels

Comments

@rschmukler
Copy link
Contributor

rschmukler commented Jul 27, 2016

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:

Tirexs.Query.create_resource(query, hits_as: %Person{})

Further benefits include the ability for those structs to be able to implement Poison.Encoder and Poison.Decoder to allow custom json 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:

  • Option A: Convert all lists to maps - This would take a lot of work but be the more performant of the two options but requires touching almost all of the code to make this change.
  • Option B: Hijack HTTP.encode to recursively convert lists into maps using Enum.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!

@Zatvobor
Copy link
Owner

Zatvobor commented Jul 28, 2016

You are right. We have to switch to [devinus/poison]. Let me think about further steps towards Option A.

Thanks.

@Zatvobor
Copy link
Owner

Zatvobor commented Aug 2, 2016

I like your proposal, but still thinking about that...

@OpakAlex
Copy link
Collaborator

@rschmukler It's a good idea, can you create some draft PR?

@mtwilliams
Copy link

+1

I've been dealing with cryptic encoding issues due toDateTime structs being passed to Tirexs.

@Electron-libre
Copy link

@mtwilliams How did you managed your issues with Tirexs and DateTime encoding ?

@mtwilliams
Copy link

@Electron-libre Manually lowered to ISO 8601.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants