To ORM or Not to ORM

Post by davidcuddeback » Tue, May 07, 2019, 6:47 PM UTC

localhostdotdev wrote: post #37

davidcuddeback wrote: post #36

Earlier quoted context omitted.

You forgot to add an index on tags.name and null constraints on the rest of the columns. > from there it's just regular rails That's the problem. Examples like this focus on the first few minutes of development. Not the subsequent years of maintenance.

I stayed close to what the author did. adding an index: add_index :tags, :name adding a null constraint: change_column :tags, :name, :string, null: false validates :name, presence: true # for proper validations https://github.com/localhostdotdev/bug/commit/3765237008c36c...

Post by ethbro » Tue, May 07, 2019, 6:50 PM UTC

topspin wrote: post #53

toast0 wrote: post #4

Earlier quoted context omitted.

All the time allegedly saved is also more than compensated for when the ORM makes bad queries that are roughly impossible to fix.

Frequently the easiest path to perform a complex query with an ORM results in N+1 performance disasters. The inevitable retort is something like "but the ORM has better ways to do that." Of course it does; ORM implementers aren't incompetent. The key word is "easiest," meaning the ORM user doesn't have to spend time learning anything beyond simply chaining method calls. In production such work goes haywire when resol…

Post by favorited » Tue, May 07, 2019, 6:55 PM UTC

toast0 wrote: post #4

ordinaryperson wrote: post #3

Sample size one 1 but ORM drives me crazy. Why can't we just use SQL? How does it save time when I have to learn the ORM language, which probably has a lot less support and users? The OP here says it "reduces boilerplate" -- rarely have I created an application and thought its biggest problem was too much boilerplate. But everyone at work loves them so I must be wrong somehow.

All the time allegedly saved is also more than compensated for when the ORM makes bad queries that are roughly impossible to fix.

Post by jweir » Tue, May 07, 2019, 6:57 PM UTC

wvenable wrote: post #42

henning wrote: post #20

I wish people did not think the choice was solely between "write raw SQL with raw strings" and "try to pretend the database is object-oriented when it is not." The third approach is to safely wrap the database and its columns with code in a way that is composable. In Python, SQLAlchemy has an ORM, but it is optional, and you can just work with tables and columns if you want.

The real third approach is that you can safely pretend the database is object-oriented for manipulation and simple lists and still use SQL for complex queries. Most ORMs let you safely mix and match both methods easily. This ORM or not ORM is the wrong question. Use an ORM to save you headaches where it's appropriate and use direct SQL when it's not.

Post by jolmg » Tue, May 07, 2019, 6:59 PM UTC

henning wrote: post #20

I wish people did not think the choice was solely between "write raw SQL with raw strings" and "try to pretend the database is object-oriented when it is not." The third approach is to safely wrap the database and its columns with code in a way that is composable. In Python, SQLAlchemy has an ORM, but it is optional, and you can just work with tables and columns if you want.

  select $ from $ \p -> do
    where_ (p ^. PersonAge >=. just (val 18))
    return p

  SELECT * FROM Person
    WHERE Person.age >= 18

  select $ from $ \p -> do
    where_ $ val "John" `isPrefixOfE` p ^. PersonName
    return p

  SELECT * FROM Person
    WHERE LEFT(Person.name, CHAR_LENGTH('John')) = 'John'