You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.
The text was updated successfully, but these errors were encountered: