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

Any interest in splitting Enumerable/Queryable into a QueryCore.jl package? #9

Open
quinnj opened this issue Apr 19, 2018 · 2 comments
Milestone

Comments

@quinnj
Copy link
Contributor

quinnj commented Apr 19, 2018

I think it would make it slightly easier for packages interopting w/ these types to have a small core to depend on (that essentially will never change); I mention because I've been digging around and have ideas around possibly enhancing the sqlite queryable implementation, or defining some methods w/ Enumerable in DataFrames itself.

@davidanthoff
Copy link
Member

Well, this package is already a split from Query.jl, i.e. my idea was that this here would be the small core :)

In terms of things that could be further split: we could certainly move out everything from the queryable folder. That stuff is super incomplete in any case right now, and I don't think it needs to be here.

The stuff in the enumerable folder is more tricky: because it is the fall-back backend it gets triggered by a method with no type restriction. If we wanted to move the iterable backend out of this package and into some other package, then that generic query function would have to live in that other package, which seems not ideal.

In terms of stability, I don't see any changes coming, and the interface definition has essentially been unchanged for a very long time (except for one short round of renames). I think a package that took a dependency on this package here and only relied on the stuff in https://github.com/davidanthoff/QueryOperators.jl/blob/master/src/operators.jl would not have to fear breaking changes. I still plan to add more query operators, but that should all be non-breaking.

A backend that properly translates things into SQL would be fantastic! You've probably seen my initial attempt here, but that literally can only translate one very specific query and nothing else, I never found the time & energy to finish that. There is a complete roadmap for this thing, though: the blog series linked to here pretty much covers it.

What would you have in mind with DataFrame? Just curious.

@davidanthoff
Copy link
Member

So the queryable stuff has now been moved out for a while. Is there anything else you think we should remove at this point?

@davidanthoff davidanthoff added this to the Backlog milestone Nov 20, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants