91–100 of 105 posts
Most engineers who say they want an ORM, really want query composition.
I think the data mapping part is pretty important: a programmatic way to map from SQL result sets to objects. That stuff is incredibly tedious (and error prone) when you do it manually.
Earlier quoted context omitted.
I think the data mapping part is pretty important: a programmatic way to map from SQL result sets to objects. That stuff is incredibly tedious (and error prone) when you do it manually.
Decomposing the result set is much simpler if the caller composed the query. Harder if you have to parse SQL to know what to expect back.
Earlier quoted context omitted.
I said it once many years ago and I still say it: "ORMs are for people who don't know SQL" However, I understand the problem it tries to solve: Object-Relational Impedance Mismatch. I only wish there were other idioms, not the convolution of classes and mappers.
I've never said this before but I'll say it now: "'ORMs are for people who don't know SQL' is usually said by people who have never written a complex application." I agree that ORMs are dangerous and clumsy for a number of use cases, but the query-building aspect is indispensable in many scenarios. Unfortunately, the query builder is usually tightly coupled to the ORM, but _if you do know SQL_ then you can use the OR…
Earlier quoted context omitted.
I've never said this before but I'll say it now: "'ORMs are for people who don't know SQL' is usually said by people who have never written a complex application." I agree that ORMs are dangerous and clumsy for a number of use cases, but the query-building aspect is indispensable in many scenarios. Unfortunately, the query builder is usually tightly coupled to the ORM, but _if you do know SQL_ then you can use the OR…
I sustain and refute your claim that I've not written complex apps. They just don't have to be complicated, which is what most ORMs bring, and has been my experience. Complex don't mean complicated.
const fights = await db.fights.get({ cardId: 9, titleFight: true }); translates to select * from fights where cardId = 9 and titleFight = 1; Confession: something about ORMs has never clicked with me.. none of them ever seem simpler than SQL.
Earlier quoted context omitted.
People usually switch to ORMs because they want to use in-language primitives for their application of choice. It's jarring and inelegant to switch between SQL and javascript or something like that. The problem with an ORM is that it's a high level abstraction On top of what is ALREADY a high level abstraction: SQL. ANd it's not even a one to one abstraction... they are very different and this actually adds more comp…
> Make an abstraction that is one to one with SQL Which SQL?
Either way the answer is this:
All the popular versions of SQL. I mean what else could the answer be? Your question was rhetorical. Trying to expose a flaw.
See the sqlalchemy expression language in sqlalchemy core. It's already very similar to what I'm proposing. It exposes something that is one to one to ansi sql. Then the underlying implementation translates that expression language into different sql languages. This is the key: Underlying implementations of ORMs typically ALREADY handle all versions of SQL languages.
What I'm proposing is a realistic extension of that. Separate APIs for EVERY sql language. You already have separate implementations... thus separate APIs is not such a crazy unrealistic extension of that.
All sql languages have common language primitives, thus an API could have two sets of libraries. One for common primitives and the other for language specific primitives. But that common library can end up being a rabbit hole, so if it's possible to do cleanly... sure, but if not then just seperate APIs for every sql language is fine.
I mean does code really need to be portable across sql databases? I wrote ORM code for postgresql, do I suddenly need that code working with SQLlite? It might be a convenience, but it's not a huge requirement.
Earlier quoted context omitted.
Not at all - in most architectures, your data objects know nothing about how they are being stored, instead delegating that to a repository class or something similar. Adding persistence logic to a data object adds all kinds of bloat - it has to have a connection to the database, which now makes unit testing a pain in the neck and introduces all kinds of weirdness around serialization. Now it has a bunch of CRUD meth…
> Adding persistence logic to a data object adds all kinds of bloat That's not what you do if you write your own queries. That's what a novice does after learning object oriented programming. For a more accurate example, look at things like Hibernate / NHibernate / Entity Framework and lazy loading. They inherit from classes at runtime and will transparently run queries as business logic navigates relationships on an…
Second, you just tried to argue for manually writing your own SQL rather than using an ORM by suggesting the way NHibernate (an ORM) does it is the right one. Might want to think up a new argument.
Finally, I used NHibernate in the past but it's gone out of favor because of the problematic things it does. Those proxies have to be runtime generated (startup cost + some extra overhead for each query) and are terrible for your data model. You have to mark properties virtual and suddenly GetType doesn't return the expected value. State tracking is actually not a great idea - causes many people to do dumb things like querying just to perform an update.
Entity Framework with state tracking turned off is better all around.
Earlier quoted context omitted.
That is an atrocity on so many levels. For one, you're creating a hard coupling to a specific flavor of SQL. And that's not too mention the fact that you're taking an otherwise purely data object and embedding persistence logic into it - a horrifying abuse of OO.
> you're creating a hard coupling to a specific flavor of SQL. I fail to see why this is a problem. Switching databases is a costly move, and is pretty rare as far as I know. When it does happen, it is usually from one type of db to another type, not between two RDBMSs. IMO it doesn't, by itself, justify sticking to an ORM rather than raw SQL.
Earlier quoted context omitted.
I'd dispute "most", as it does not match my experience across a number of languages. Yes, active record sorta does it but, as best I recall, those methods are all implemented generically as mixins, so not actually a part of the data object. This seems to be advocating for data specific queries to be added to each class.
Rails and Django are both AR, and are still probably the two most widely used backend frameworks, for better or for worse. I don’t disagree with the overall point you’re making, I’m just pointing out that it’s very common
Even if they did the same thing you're suggesting, by that logic, we should all use PHP because WordPress does, and it's probably more popular than those two combined.
Take a look at something like Spring or Entity Framework to see other takes on ORM patterns.
And again, you're trying to argue against ORMs, while citing that your suggested alternative is supported by the way ORMs do it.
Earlier quoted context omitted.
Rails and Django are both AR, and are still probably the two most widely used backend frameworks, for better or for worse. I don’t disagree with the overall point you’re making, I’m just pointing out that it’s very common
Ummm... No. See my previous comment - at least in Rails, the queries aren't part of the data object themselves, but are instead mixins or default handlers (don't recall which offhand), so it's really just syntactic sugar that makes it appear as though they are methods on the data class. Even if they did the same thing you're suggesting, by that logic, we should all use PHP because WordPress does, and it's probably mo…
I don’t see what the nuance is you’re getting at with the mixin vs object method argument though. They both have the same issues around testability and violation of SRP.