141–150 of 160 posts
Earlier quoted context omitted.
> but I wanted something more lightweight it's called "sqlalchemy core" https://docs.sqlalchemy.org/en/20/core/
SQLAlchemy Core isn't an ORM, it's just a very good query generator. Although nobody seems to use the term ORM correctly any more so it's entirely possible that neither is peewee or sqlorm. The story behind why ORM is nowadays no longer used correctly is kind of funny: 1. Query generator sounds primitive, like cavemen banging rocks together. Software engineers are scared of primitive technologies because it makes the…
It is still basically a query generator, just with the helpful step of converting selected tuples into objects, and tracking changes to those objects. This means that it is often possible to solve ORM-related performance issues without too much work.
It’s been a long time since I worked with SQLAlchemy though (or even touched Python), so my memory or knowledge of the current ecosystem might be off.
https://www.jetbrains.com/guide/dotnet/tutorials/htmx-aspnet...
Earlier quoted context omitted.
Surely you’re not saying the frameworks famous for ui = f(state) actually suck at managing state…
If it only were true. React is nothing like ui = f(state). More like ui = f(some_trivial_state) + lifecycles magic + probably global_state. Garbage. But effective devrel.
For instance, you could entirely forgo the influence of lifecycles and global state by putting everything in a top-level Context with 1 state object that you only ever update by calling `setState`.
After that, you might find reasons to optimize your app, which could lead you to more interesting approaches like reducers or state management libraries or memoization, but I'm guessing you would never get that far and just go back to what you were doing before, since YOUR preferences are battle hardened and reliable software, while things you don't know about are only popular because of Facebook. Obviously.
Earlier quoted context omitted.
If it only were true. React is nothing like ui = f(state). More like ui = f(some_trivial_state) + lifecycles magic + probably global_state. Garbage. But effective devrel.
This type of dismissive attitude is so strange to me. The only reason "lifecycles magic + probably global_state" would be causing your app to behave unpredictably is - this is going to shock you - because you closed your mind to a tool by dismissing it as garbage before you used it, and then failed to use it properly because you think its popularity boils down to PR. For instance, you could entirely forgo the influen…
Earlier quoted context omitted.
Too heavy. Too many abstractions. It always gets in my way.
It's not heavy. The abstrations allow for consistent query compositions from reusable expressions. Demonstrate how you do conditional query building for everyone to witness the way.
Earlier quoted context omitted.
> but I wanted something more lightweight it's called "sqlalchemy core" https://docs.sqlalchemy.org/en/20/core/
SQLAlchemy Core isn't an ORM, it's just a very good query generator. Although nobody seems to use the term ORM correctly any more so it's entirely possible that neither is peewee or sqlorm. The story behind why ORM is nowadays no longer used correctly is kind of funny: 1. Query generator sounds primitive, like cavemen banging rocks together. Software engineers are scared of primitive technologies because it makes the…
I’ve written a few ORMs and you have the same performance executing a select and getting rows back and translating them into objects than you do my ORMs. It’s literally the same. Are you going to return back a Row* from your function? No. You’re going to return an object or an array. Building that from an array of rows is no different than an ORM mapping those rows for you using instructions on what field goes where.
Just like you do in your function to build an object. “Oh but it’s at compile time!” You’ll shout. So are mine. CodeGen exists. The real issue you experience is that a certain style of ORMs confuse you. Unit of work or ActiceRecord pattern style ORMs can literally be codegen’ed into your binary to make mapping as fast as new() {}.
ORMs provide you with objects and relationships. Some of them even do validation should you choose. It’s about correctness and not going Wild West on your database with no regard to schema or normalization. If you’re properly normalized, you’ll be thankful for ORMs saving you from the JOIN hell you so desperately hang on to.
Earlier quoted context omitted.
This type of dismissive attitude is so strange to me. The only reason "lifecycles magic + probably global_state" would be causing your app to behave unpredictably is - this is going to shock you - because you closed your mind to a tool by dismissing it as garbage before you used it, and then failed to use it properly because you think its popularity boils down to PR. For instance, you could entirely forgo the influen…
So, redux? It's either redux or, sorry, "lifecycles magic + probably global_state". And who uses redux in 2025?
Earlier quoted context omitted.
It's not heavy. The abstrations allow for consistent query compositions from reusable expressions. Demonstrate how you do conditional query building for everyone to witness the way.
Intermediate data structure -> compile to SQL
Earlier quoted context omitted.
SQLAlchemy Core isn't an ORM, it's just a very good query generator. Although nobody seems to use the term ORM correctly any more so it's entirely possible that neither is peewee or sqlorm. The story behind why ORM is nowadays no longer used correctly is kind of funny: 1. Query generator sounds primitive, like cavemen banging rocks together. Software engineers are scared of primitive technologies because it makes the…
This is complete nonsense. I’ve written a few ORMs and you have the same performance executing a select and getting rows back and translating them into objects than you do my ORMs. It’s literally the same. Are you going to return back a Row* from your function? No. You’re going to return an object or an array. Building that from an array of rows is no different than an ORM mapping those rows for you using instruction…
I didn't say you didn't want a query generator, or to have some way of mapping things automatically to native types so you are not effectively dealing with native database types.
What you don't want, which is what object relational mapping means / was designed to solve, is to force your relational data into being represented as a graph of objects when you operate on that data within your application.
To finalize:
ORMs use query generation, but they are not the originators or the only source of query generators
ORMs often provide additional validation, but they are not the originators or the only source of validation
ORMs by their definition map your SQL data to your native types, but fundamentally they do it in a way which cannot be made performant at scale. You can map things to your native types in a way which is performant but this would definitionally not be an ORM