21–30 of 41 posts
https://ibis-project.org/ is another great alternative. It provides a fluent/linq style api but doesn't abstract the SQL away too much.
Interesting.
Looks like theyre headed in the right direction. ORMs are tricky to get right, when I wrote ClojureQL I looked more towards combinatorics than SQL: https://clojureql.sabrecms.com/en/examples
Your example of multiple sorts is problematic. > SELECT * FROM (SELECT users.* FROM users ORDER BY users.id asc) ORDER BY users.id desc A sort should never (for some value of never) appear in a subquery because it's meaningless; it can't affect the result. In tsql it's explicitly checked for and reported. Not having a go, just fyi. Edit: now I'm more confused by that. The bracketed subquery doesn't have a name but it…
https://ibis-project.org/ is another great alternative. It provides a fluent/linq style api but doesn't abstract the SQL away too much.
What about SQLAlchemy makes it unfriendly for analytics code? The last time I looked at it, SQLAlchemy Core had a pretty good fluent interface for writing SQL queries
I think this is really neat. It’s seems a bit more flexible than the composition approach of SQLAlchemy, too. I also like that the unit of composition is the CTE.
Can you say more about that? I though SQLAlchemy core goal was exactly that. When does it fails, compared to Csql?
SQLAlchemy can't give me that, instead I'd need to learn a special SQLAlchemy-specific query builder syntax that probably won't support all the analytical functions I want to use anyway. It's really a whole different beast to csql.
Q("""select 1 from {otherQuery}""")
Q(lambda: f"""select 1 from {otherQuery}""")This project seems nice, but there's some detail I have trouble wrapping my head around: why is a template string represented as a lambda containing an f-string, instead of as a plain string? Namely, wouldn't the code below suffice? Q("""select 1 from {otherQuery}""") What does the following code enable that the code above cannot do? Q(lambda: f"""select 1 from {otherQuery}""")
function Q(stringBits: string[]): Query {
for (bit in stringBits) {
if (bit is string) {
add to sql
} else if (bit is Query) {
add bit to dependencies
add bit.name to sql
}
}
}
Suggestions for improvements are welcome!
As an analyst, I often am faced with a choice between - write a giant unmaintainable SQL query, or - pull everything to my PC and use pandas, to take advantage of its ability to build up results piece by piece. I wrote this library to try and enable that piece-by-piece development approach with SQL queries, without resorting to the mental overhead of full on query builders like SQLAlchemy or Linq. Seeking feedback -…
I second the recommendation for dbt. Especially if you're following an ELT architecture where you load your data into a data warehouse and then want to transform it. However dbt is more useful for transforming existing data, or aggregating data in batches. It's not a tool for generating SQL expressions on-the-fly like your library would allow you to do.
This project seems nice, but there's some detail I have trouble wrapping my head around: why is a template string represented as a lambda containing an f-string, instead of as a plain string? Namely, wouldn't the code below suffice? Q("""select 1 from {otherQuery}""") What does the following code enable that the code above cannot do? Q(lambda: f"""select 1 from {otherQuery}""")
It's impossible to hook into Python's string interpolation system to the degree required for the first to work. JS and Julia can do it, e.g. in JS (with typescript annotations) it'd just be a matter of defining function Q(stringBits: string[]): Query { for (bit in stringBits) { if (bit is string) { add to sql } else if (bit is Query) { add bit to dependencies add bit.name to sql } } } But this cannot be done currentl…
As an analyst, I often am faced with a choice between - write a giant unmaintainable SQL query, or - pull everything to my PC and use pandas, to take advantage of its ability to build up results piece by piece. I wrote this library to try and enable that piece-by-piece development approach with SQL queries, without resorting to the mental overhead of full on query builders like SQLAlchemy or Linq. Seeking feedback -…
https://github.com/machow/siuba
One thing I was wondering about the gnarly ast stuff you mention, what about operator overloading? E.g. Q("Select a from" + subquery + "where a < 1")