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

Multiple callbacks on one streaming parser? #9

Closed
cben opened this issue Sep 27, 2017 · 3 comments

Comments

@cben
Copy link

commented Sep 27, 2017

It seems from README / tests / code that currently one JsonStreamer expects to have exactly one .get / .get_with_conditions callback.
If one wants to extract several parts, the expected way is instantiate multiple JsonStreamer and feed same data to them all?

For our current use case, this is perfectly OK, just wanted to confirm, and have this for tracking.
In some cases single-parser-multiple-callbacks could be faster, and I expect it's doable in principle with the underlying SAX-like gem. Maybe I'll implement this one day...

(It may already be possible to abuse Conditions with complex lambda(s) but that's no fun. The goal here is independent callback blocks.)

@thisismydesign

This comment has been minimized.

Copy link
Owner

commented Sep 27, 2017

Yes, only one .get or .get_with_conditions callback is expected. This is a good point, I will make it explicit in the README.

As you figured it's possible to match multiple items with complex conditions or even with using both key and nesting_level parameters with get.

It's also true that a single-parser-multiple-callbacks is in principle doable and could be faster in these cases.

One thing to keep in mind with future and current implementation is that we currently throw away yielded data, otherwise the purpose of streaming would be defeated. Because of this nested results are problematic. I.e. if you yield something that could later be a part of another match it will no longer be available. So in some SAX callbacks we'd need to check whether the partial data could be matched in the future before we remove it. I think this is not an issue for get but not sure about the current way of non-explicit custom conditions.

In any case, it would be a nice improvement. :)

@thisismydesign

This comment has been minimized.

Copy link
Owner

commented Sep 29, 2017

Updated the README. If you're ok with it please close the issue.

@cben

This comment has been minimized.

Copy link
Author

commented Sep 29, 2017

👍

@cben cben closed this Sep 29, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.