4 ms·

Interesting. I love requests. SQL isn't my area of expertise so im genuinely surprised in 2016 we're still building libraries like this for Python; are existing

by Wonnk13 11y ago

Interesting. I love requests. SQL isn't my area of expertise so im genuinely surprised in 2016 we're still building libraries like this for Python; are existing libraries really that bad?

benatkin 11y ago
This works on multiple databases, yet still uses plain old sql. I think it's simpler than using a multi-database ORM for plain old sql, or using a databases' driver directly, like psycopg2. Edit: actually it just works on postgres. I don't know if there are plans to make it work on other SQL databases.
- monkmartinez 11y ago
  Really? Have you looked at the code? It looks like it's hardwired to psycopg2 and only works with Postgres. I could be wrong.
  - benatkin 11y ago
    I have now, and you are correct. It also says so in the README. The API looks like it's designed to be compatible with any SQL database, though.
  - Chirael 11y ago
    The github page says "Records is a very simple, but powerful, library for making raw SQL queries to Postgres databases" - so it does seem PG specific
ForHackernews 11y ago
> are existing libraries really that bad? I would say 'no'. SQLAlchemy is very good, but extremely complex and powerful. I think people don't understand that you can use the core features without any of the ORM overhead, if you don't want it. If you want to "Just write SQL" you can do that, easily: http://docs.sqlalchemy.org/en/latest/core/tutorial.html#using-textual-sql http://docs.sqlalchemy.org/en/latest/core/tutorial.html#usin...
- mastazi 11y ago
  I'm just curious: in the first example of the section that you linked, what's the purpose of the "|| ', ' || " bit? I think the double pipe is used for concatenation in SQL, but I don't understand why the ', ' part needs to be concatenated like that.
  - zzzeek 11y ago
    that example is intending to produce a single column result that concatenates two fields into a comma-separated string, e.g. "your name, you@somesite.com". I think jumping into that example directly is probably kind of disorienting. The SQL in that string is a little bit weird/contorted just to illustrate, "it's text, do whatever you want!". I also wrote that example like ten years ago.
    - mastazi 11y ago
      Oh OK I get it, it makes perfect sense but yes, jumping to that example directly might be disorienting. Maybe a one-line explanation (just like the one you gave me) placed immediately above or below the code example would make it more readable!
Finnucane 11y ago
SQLAlchemy tries to provide a pythonic wrapper for most database operations, in an implementation-agnostic way, which can be a convenience but also makes it large and complex. It really isn't the thing you want to use if what you want is to just send a plain snippet of SQL to your database. There isn't a simple 'requests-for-sql' type of thing, until now.
njharman 11y ago
[edit] despite negative expectations, I still upvoted OA cause even "wrong" innovation is better than stagnation. pyscopg2 is pretty great. Every lib I've seen is based on it. Many apps use it directly. It is the lowest, comfortable layer you'd want. What you need on top of that is Either; 1) So minor, most just write a few helper functions/classes 2) So elaborate and opinionated it needs years of use/work to get right. SQLAlchmey, Django ORM. 3) So specific, customized to your requirements that general purpose libs/frameworks don't fit. Some people get tired of redoing #1 or don't like #2's opinions or think there should be something lighter. So, they build something they hope to be middle ground. I don't think there is a middle ground. As you use it you realize the complexity (dbs/SQL are much, much more complicated/powerful than you think, the impedance between relations and objects) and middle ground projects remain "toys" or grow into SQLAlchemy.
morelikeborelax 11y ago
No they aren't, this just looks like an itch that has been scratched. Outside of the ORM libraries there isn't much fanfare for this sort of thing though. I spent a couple of hours looking for exactly this yesterday for a new Tornado based project and ended up using queries: https://github.com/gmr/queries https://github.com/gmr/queries which seems on the same level for my purposes of wanting to cleanly pass raw SQL and get python data structures in return. Queries also provides asynchronous API interaction with Tornado which will be nice for me. Coincidently queries was inspired by Kenneth Reitz's work on requests. I think it is often tempting to write something like this as it is quite a light thing and can reacquaint someone with SQL if they haven't used it for a while. I know I was tempted after pouring through ORMs.
hobarrera 11y ago
> are existing libraries really that bad? No, but they're meant for other use-cases. This fills in a gap for "simple, but powerful", as advertised. :)

by Wonnk13 11y ago

Interesting. I love requests. SQL isn't my area of expertise so im genuinely surprised in 2016 we're still building libraries like this for Python; are existing libraries really that bad?

benatkin 11y ago

This works on multiple databases, yet still uses plain old sql. I think it's simpler than using a multi-database ORM for plain old sql, or using a databases' driver directly, like psycopg2. Edit: actually it just works on postgres. I don't know if there are plans to make it work on other SQL databases.

monkmartinez 11y ago
Really? Have you looked at the code? It looks like it's hardwired to psycopg2 and only works with Postgres. I could be wrong.
- benatkin 11y ago
  I have now, and you are correct. It also says so in the README. The API looks like it's designed to be compatible with any SQL database, though.
- Chirael 11y ago
  The github page says "Records is a very simple, but powerful, library for making raw SQL queries to Postgres databases" - so it does seem PG specific

ForHackernews 11y ago

> are existing libraries really that bad? I would say 'no'. SQLAlchemy is very good, but extremely complex and powerful. I think people don't understand that you can use the core features without any of the ORM overhead, if you don't want it. If you want to "Just write SQL" you can do that, easily: http://docs.sqlalchemy.org/en/latest/core/tutorial.html#using-textual-sql http://docs.sqlalchemy.org/en/latest/core/tutorial.html#usin...

mastazi 11y ago
I'm just curious: in the first example of the section that you linked, what's the purpose of the "|| ', ' || " bit? I think the double pipe is used for concatenation in SQL, but I don't understand why the ', ' part needs to be concatenated like that.
- zzzeek 11y ago
  that example is intending to produce a single column result that concatenates two fields into a comma-separated string, e.g. "your name, you@somesite.com". I think jumping into that example directly is probably kind of disorienting. The SQL in that string is a little bit weird/contorted just to illustrate, "it's text, do whatever you want!". I also wrote that example like ten years ago.
  - mastazi 11y ago
    Oh OK I get it, it makes perfect sense but yes, jumping to that example directly might be disorienting. Maybe a one-line explanation (just like the one you gave me) placed immediately above or below the code example would make it more readable!

Finnucane 11y ago

SQLAlchemy tries to provide a pythonic wrapper for most database operations, in an implementation-agnostic way, which can be a convenience but also makes it large and complex. It really isn't the thing you want to use if what you want is to just send a plain snippet of SQL to your database. There isn't a simple 'requests-for-sql' type of thing, until now.

njharman 11y ago

[edit] despite negative expectations, I still upvoted OA cause even "wrong" innovation is better than stagnation. pyscopg2 is pretty great. Every lib I've seen is based on it. Many apps use it directly. It is the lowest, comfortable layer you'd want. What you need on top of that is Either; 1) So minor, most just write a few helper functions/classes 2) So elaborate and opinionated it needs years of use/work to get right. SQLAlchmey, Django ORM. 3) So specific, customized to your requirements that general purpose libs/frameworks don't fit. Some people get tired of redoing #1 or don't like #2's opinions or think there should be something lighter. So, they build something they hope to be middle ground. I don't think there is a middle ground. As you use it you realize the complexity (dbs/SQL are much, much more complicated/powerful than you think, the impedance between relations and objects) and middle ground projects remain "toys" or grow into SQLAlchemy.

morelikeborelax 11y ago

No they aren't, this just looks like an itch that has been scratched. Outside of the ORM libraries there isn't much fanfare for this sort of thing though. I spent a couple of hours looking for exactly this yesterday for a new Tornado based project and ended up using queries: https://github.com/gmr/queries https://github.com/gmr/queries which seems on the same level for my purposes of wanting to cleanly pass raw SQL and get python data structures in return. Queries also provides asynchronous API interaction with Tornado which will be nice for me. Coincidently queries was inspired by Kenneth Reitz's work on requests. I think it is often tempting to write something like this as it is quite a light thing and can reacquaint someone with SQL if they haven't used it for a while. I know I was tempted after pouring through ORMs.

hobarrera 11y ago

> are existing libraries really that bad? No, but they're meant for other use-cases. This fills in a gap for "simple, but powerful", as advertised. :)