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

Extending top-level ("cached") params #70

Open
rkaw92 opened this issue May 12, 2016 · 1 comment
Open

Extending top-level ("cached") params #70

rkaw92 opened this issue May 12, 2016 · 1 comment

Comments

@rkaw92
Copy link

rkaw92 commented May 12, 2016

Currently, the operators that should be "bubbled up" to the top level (exports.lastSeen) are only found in a module variable and can be configured library-wise. However, this is dangerous in combination with caching module systems. For instance, in Node.js, requiring the same module twice will re-use the module object and only create a new reference to it.

As I will be extending RQL with some custom operators for keyset-based paging that still need to impact query behavior as a whole, altering "lastSeen" is a necessity for my use case. However, I would very much like to avoid this modification of a global module instance at runtime, because it may break other users of the library in the same application.

This is why I believe the parser API should expose a class (constructor function?) that allows per-instance parser configuration. Moreover, this can be done without breaking API compatibility by making the value of exports an instance of the Parser.

Please let me know what you think of this rather significant refactoring.

@rkaw92
Copy link
Author

rkaw92 commented May 18, 2016

For now, I have solved this by traversing the parsed AST and gathering "interesting" top-level operators in much the same way that rql proper does it. Still, configurability on an instance basis would be most welcome.

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

No branches or pull requests

1 participant