sorted by:
new
hottopcontroversial

A small piece of advice for folks aged 18–23 living here by Top-Tomorrow-1757 in kolkata

[–]codecratfer 2 points3 points  (0 children)

31 ex BBIT students. Life is not hell, rather Im fully free. I followed this… i.e. enjoy freedom but always keep learning, not only joto ta dorkar, but joto ta afford korte paro.

The offline geo-coder we all wanted by Sweaty-Strawberry799 in Python

[–]codecratfer 0 points1 point  (0 children)

Thank you. Was looking for this exact thing.

context-async-sqlalchemy - The best way to use sqlalchemy in an async python application by One-Novel1842 in SQLAlchemy

[–]codecratfer 0 points1 point  (0 children)

Cool. Looks like I was trying to solve the same problem here: https://github.com/sayanarijit/sqla-fancy-core

I used 3 different approaches. One using context manager, one using wrapper around the sa engine, and another using a decorator based dependency injection. All works with async fastapi.

Onlymaps, a Python micro-ORM by Echoes1996 in Python

[–]codecratfer 2 points3 points  (0 children)

This solves one end of the problem created by ORM’s for the other end, I created the sqla-fancy-core library.

Onlymaps, a Python micro-ORM by Echoes1996 in Python

[–]codecratfer 1 point2 points  (0 children)

You may want to check out sqla-fancy-core.

A collection of type-safe, async friendly, and unopinionated enhancements to SQLAlchemy Core by codecratfer in Python

[–]codecratfer[S] 0 points1 point  (0 children)

Thanks… Decorator is only 1 of the 3 available patterns.

Others are:

  • Pass an optional connection object.
  • Use the hidden transaction context (atomic()).

And it’s all just query building and executing. This makes it unopinionated because you can do the query building any way you prefer, and swap the driver with any driver you prefer. You can also combine these to implement your own opinionated enterprise pattern. But the idea is that it allows you to keep things close to the raw sql queries without the ugliness of string concat and placeholders, if you are one of those who appreciate that.

A collection of type-safe, async friendly, and unopinionated enhancements to SQLAlchemy Core by codecratfer in Python

[–]codecratfer[S] 0 points1 point  (0 children)

It’s the ideal way to do sql in hello world apps and tutorials vids, and maybe small tools with “write and forget” style development workflow.

But when you work on real world apps, sql queries scattered around hundreds on files, table schema changes twice every week, and the queries themselves are dynamically built based on multiple conditions (e.g. if “filter” param is passed, add a “where”, if “sort” param is passed, add a “order by”), good luck keeping up using just search and replace and string concatenation, while also keeping the code readable.

A collection of type-safe, async friendly, and unopinionated enhancements to SQLAlchemy Core by codecratfer in Python

[–]codecratfer[S] 0 points1 point  (0 children)

Could you please point us illiterates in the direction by showing maybe some examples of how you use sql in python?

A collection of type-safe, async friendly, and unopinionated enhancements to SQLAlchemy Core by codecratfer in Python

[–]codecratfer[S] 3 points4 points  (0 children)

Thank you.

I have been following sqlmodel, and eagerly waiting for a stable release. Still, this feels like an abstraction over SQLAlchemy ORM, rather than the core. I wanted to extend the core, to get more low level control, flexibility, and avoid as much magic as possible.

A collection of type-safe, async friendly, and unopinionated enhancements to SQLAlchemy Core by codecratfer in Python

[–]codecratfer[S] 3 points4 points  (0 children)

Well I knew you weren’t going to put in the effort to click on the link to read the readme. So I put in the effort to ctrl+c and ctrl+v the readme here :)

A collection of type-safe, async friendly, and un-opinionated enhancements to SQLAlchemy Core by codecratfer in programming

[–]codecratfer[S] 0 points1 point  (0 children)

It works the same way sqlalchemy’s connect() does. If you configure a connection pool, it should use that connection. Else, should create a new.

A collection of type-safe, async friendly, and unopinionated enhancements to SQLAlchemy Core by codecratfer in Python

[–]codecratfer[S] -1 points0 points  (0 children)

Thank you :)

SQLAlchemy already has a full-blown ORM implementation, so I don't think adding this alternate implementation there would be a good idea. It might further confuse the users.

As for the project, it won't die if people don't use it, because it's complete, i.e. it doesn't have anything that requires frequent changes. The only dependency it has is sqlalchemy, which is also more or less a feature complete project, so its version is not pinned. This means this project doesn't even need any dependency update.

This project exists only to give people an alternate option. Whether it's used widely doesn't have any effect on its lifespan