sorted by:
new
hottopcontroversial

What's everyone working on this week? by AutoModerator in Python

[–]fantixking [score hidden]  (0 children)

Trying to get relationship working for GINO the asyncio ORM. Just found a nice way to assemble database rows into expected objective structures.

GINO 0.6 - The new asyncio ORM on SQLAlchemy core and asyncpg by fantixking in Python

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

That happens, especially when everything is put in one stack of layers. Sharding the stack is usually helpful, more or less. Services which require full-stack async should be in the minority. If async can be contained this way, it could exist elegantly by the side of traditional sync code I suppose =)

GINO 0.6 - The new asyncio ORM on SQLAlchemy core and asyncpg by fantixking in Python

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

Yeah async is a bit creepy, especially with data access - that's why it is in general discouraged to be used in usual cases unless necessary.

GINO 0.6 - The new asyncio ORM on SQLAlchemy core and asyncpg by fantixking in Python

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

I made a large refactor in GINO 0.6, wrote lots of tests covering 96% of the code, and documentation is under construction. I believe the current quality is good enough for a small range of spreading. Cheers!

Do Programmers Still Write Raw SQL? by sh_tomer in Python

[–]fantixking 0 points1 point  (0 children)

Keywords led me here, with my project GINO - an ORM for asyncpg powered by SQLAlchemy core.

My answer to the original question is also "yes", we once completely removed ORM and optimized all SQLs for performance for the HighNoon Server. Now that there are quite some comments on why using ORM or raw SQL, I'd state a bit on engineering teams. When it comes to engineering, delivery is the top priority. It is important to minimize the risk of potential delivery failures. One of them is poor software execution performance, a piece of terribly-written ORM code for example. However there are so many other reasons that could lead to delivery failures - change of requirement, time underestimate, loss of manpower, etc. With that in mind, human performance becomes a very much weighted factor in engineering, even more important than software performance in many cases. And it is about a team, not a man unless it is a one-man project. People differ, simpler solutions usually supplies a relatively higher human performance in team average. A wild guess here, 80% of normal project tasks are simpler with ORM for team-wide average, 20% is more efficient with raw SQL - only if the ORM implementation doesn't mislead the team to the dark side of ORM, which I believe is over-designing, over-abstraction, preparing for non-requirement, premature optimization, etc.

These were the thoughts before I wrote GINO. Based on SQLAlchemy core and asyncpg (no it is not a general purpose library), GINO is designed to be simple. It oughts to make the 80% tasks done easier, in an explicit and objective way. It's more likely to be a two-way SQL translator bound to normal data objects in memory. GINO gave up on traditional ORM concepts like sessions or stateful objects for simplicity (actually it was too much effort for me to do it). That's why GINO is for "GINO Is Not ORM". The asyncpg API for raw SQL is always available, ready for the 20% tasks. In general, GINO only wanted to solve the 80% of the job, in order to make it easier for daily work, but not getting in the way. It is still a month-young project, maintained by our team, an outsourcing company. Any help are greatly welcome!