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
Closed

Multiple callbacks on one streaming parser? #9

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

Comments

@cben
Copy link

cben 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
Copy link
Owner

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
Copy link
Owner

thisismydesign commented Sep 29, 2017

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

@cben
Copy link
Author

cben commented Sep 29, 2017

👍

@cben cben closed this as completed Sep 29, 2017
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

2 participants