Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

To ORM or Not to ORM

eli.thegreenplace.net

Post reply on HN
Print view View original

191–200 of 300 posts

Re: To ORM or Not to ORM

#191

Post by dragonwriter »

Dayshine wrote: post #167
dragonwriter wrote: post #130

Earlier quoted context omitted.

> Say for instance we have one query that finds eligible bachelors near me and another that finds newly eligible bachelors. We need two queries but they both rely on the same underlying domain concept of "eligible bachelors". [...] It's hard to do that in sql in a maintainable way. Seems a textbook case of using a view for sharing query logic. > If I decide to change a datetime field called time to split it into a da…

>Seems a textbook case of using a view for sharing query logic. Views are just terrible outside of data analyst style work. Unmaintainable, restricted to SQL structures, require absurd hacks or custom dlls, not properly source controlled, difficult to perform performance analysis on, hard to update. You can't combine views easily, you can't cache results, you don't get static type checking.

> Unmaintainable,

Views are not "unmaintainable".

> restricted to SQL structures,

I'm not sure how that's a problem, since SQL is a fully-general data language.

> require absurd hacks or custom dlls,

Views require neither hacks nor "custom DLLs" in any RDBMS I am aware of. Can you provide a concrete example?

> not properly source controlled,

There's no reason DB schemas (including, but not limited to, view definitions) can't be source controlled.

> You can't combine views easily

Yes you can, whether by "combine" you mean as joined source relations, or as criteria that need to be combined to slice and dice the same source data. That's, like, playing right to the strength of SQL and RDBMS systems.

> you can't cache results,

Well, not generally incrementally or in something like a recently-used cache; a number of RDBMS's do support materialized views, though.

Re: To ORM or Not to ORM

#192

Post by ilovetux »

marcosdumay wrote: post #146
ilovetux wrote: post #26

I like the Django ORM. This is likely for two reasons: 1. I only use Django for small use cases where I rarely see any sort of scope creep. There was no real conscious decision about this, just kind of the way it happens. 2. The Django ORM is fairly mature and makes it quite easy to get a small project out the door. I regularly use SQL directly at work and wouldn't want to try to replace any of it with an ORM even on…

For me, the best feature of the Django ORM is that it integrates with everything all the way to the frontend forms. In fact, missing the database integration wouldn't even be that large loss. Sometimes I wonder if it isn't even holding the framework back.

I agree the ModelForm class is great.

Re: To ORM or Not to ORM

#193

Post by dllthomas »

ozim wrote: post #111
bunderbunder wrote: post #97

I've come to a couple conclusions, over the years. First, when you get down to it, the most-valued feature of ORMs is not the "writing queries in some language other than SQL" feature, it's the "not having to write a mess of mapping code" feature. Second, the biggest drawbacks to ORMs all derive from the "writing queries in some language other than SQL" feature. Fortunately, there are tools out there that solve the "…

Actually "writing queries in some language other than SQL" which has static typing and catching issues in compile time is quite big for me. Add automatic database migrations that are also keeping types in line with code and whole bunch of "mess of mapping code" goes away. Though I use .NET EntityFramework which by now is really mature and heavily invested into by MS. Not sure how it is with other environments but I t…

I've been wanting to build static typing for raw sql atop https://github.com/uber/queryparser

Re: To ORM or Not to ORM

#194

Post by spion »

bunderbunder wrote: post #97

I've come to a couple conclusions, over the years. First, when you get down to it, the most-valued feature of ORMs is not the "writing queries in some language other than SQL" feature, it's the "not having to write a mess of mapping code" feature. Second, the biggest drawbacks to ORMs all derive from the "writing queries in some language other than SQL" feature. Fortunately, there are tools out there that solve the "…

I've come to the exact opposite conclusion.

The query DSL for ORMs is fine, works well in a large majority of the situations. When it gets problematic, you can almost always drop down to pure SQL.

The mapping part of the ORM on the other hand is a disaster. Table rows make poor OO classes. The best OO classes are "workers" that have some concrete task at hand. "Active record" style classes have no scope whatsoever - anything connected to the data can be potentially added to the model class.

So on projects with ORMs my main problem is dealing with the responsibility spaghetti. Typically one class which is the central point of the domain grows to crazy proportions. In a document-related software for example, you can potentially put everything in a "Document" entity class. "DocumentConverter" on the other hand has clear responsibility scope - to convert documents - but of course, a converter doesn't have a database table.

Re: To ORM or Not to ORM

#195

Post by philwelch »

Falling3 wrote: post #183
philwelch wrote: post #107

Earlier quoted context omitted.

Two caveats with find_by_sql: it’s read-only, so no insert or update commands, and it still does column-to-instance-variable monkeypatching on the object level, as opposed to the class-level monkeypatching that’s applied to normal ActiveRecord classes as soon as the DB schema is read.

For the former, there's always ActiveRecord::Base.connection.execute. For the latter, I think it's more complicated than that. There also is object-level mapping even for regular AR usage. If you do something like Foo.select("true as bar"), your Foo objects will have a bar variable available to them.

This is true.

Re: To ORM or Not to ORM

#196

Post by stickfigure »

bunderbunder wrote: post #97

I've come to a couple conclusions, over the years. First, when you get down to it, the most-valued feature of ORMs is not the "writing queries in some language other than SQL" feature, it's the "not having to write a mess of mapping code" feature. Second, the biggest drawbacks to ORMs all derive from the "writing queries in some language other than SQL" feature. Fortunately, there are tools out there that solve the "…

Fortunately, there are tools out there that solve the "mapping tables to objects" problem without trying to control all access to the database

...like, say, Hibernate.

I have a reasonably mature Hibernate app. It is almost exactly as easy to type createNativeQuery() as it is to type createQuery(). Many simple queries are shorter in JPQL, but for anything complex I always use SQL. I never feel like Hibernate is keeping me apart from the database.

I genuinely think most people who bash ORMs just haven't gotten far enough in their SQL learning curve that they get tired of writing the same dumb I/O code over and over. ORMs never "freed you from SQL", they just freed you from boilerplate. Even venerable and much-maligned ORMs like Hibernate.

Re: To ORM or Not to ORM

#197

Post by alexnewman »

jeltz wrote: post #127
ozim wrote: post #111

Earlier quoted context omitted.

Actually "writing queries in some language other than SQL" which has static typing and catching issues in compile time is quite big for me. Add automatic database migrations that are also keeping types in line with code and whole bunch of "mess of mapping code" goes away. Though I use .NET EntityFramework which by now is really mature and heavily invested into by MS. Not sure how it is with other environments but I t…

I have tied to use automatic migrations and I do not see the point. Either your diff is trivial and it is trivial to write a migration or your diff is complex and you have to care about the lock levels of schema changes, the time complexity of changes and that the migration transforms data correctly. The code generating the automatic migrations needs knowledge about the structure of the production data.

exactly

Re: To ORM or Not to ORM

#198

Post by kiliancs »

out_of_protocol wrote: post #102

For everyone complaining about orm-something - take a look at elixir's Ecto. It basically allows writing sql via native code. Good for composability, type casting, stuff like that. Account |> where(active: true) |> join(:left, [a], p in Post, on: p.account_id == a.id) |> where([a, p], a.foo == "bar" or p.bar == "foo") |> group_by([a, p], a.id) |> select(...) |> limit(10) ... |> Repo.all() Plus there are changesets fo…

This is the best solution I've found so far. Bring sql to the language instead of abstracting it. Plus changesets, migrations, etc.

Re: To ORM or Not to ORM

#199

Post by radiowave »

OJFord wrote: post #161
lenkite wrote: post #152

Earlier quoted context omitted.

We use liquibase https://www.liquibase.org/ for tracking, managing and applying any schema changes. The liquibase changelogs are part of our project releases.

> Supports XML, YAML, JSON and SQL formats XML is the default on the page, but wow the SQL is _so_ much shorter and more readable than the others! To the extent that I wonder what's the point, the obvious is machine readabaility, but one not three, and is SQL really so machine-unreadable that it's worth the extra depth and complexity?

With Liquibase, when you write changesets using SQL, you have to write the rollback code yourself. When you write them with Liquibase's built-in operations in (for example) XML, the rollback is derived automatically.

I write SQL almost daily, but for the things that can easily be expressed with Liquibase's operations, I can write them faster and with fewer errors in XML, so long as I'm using a text editor with XML schema support (hence: autocompletion and validation as-you-type). PyCharm works well for this.

Re: To ORM or Not to ORM

#200

Post by tmefq »

OJFord wrote: post #163
runin2k1 wrote: post #150

Earlier quoted context omitted.

Of course it does. Not that a little detail like that would stop someone from complaining about something that they don't put in the effort to learn.

If you just use that all the time, your coworkers will rightly complain that it's not idiomatic or using the tooling available in code review. I'm all for SQL, but if the project's set in its ORM then it doesn't make sense to do ORM.raw(...) or whatever out of preference alone.

Yes that's what happened to me. Project requirements.
Post reply on HN