[localhostdotdev]

    rails g model Post published_at:datetime title content:text
    rails g model Comment post:references author published_at:datetime content:text
    rails g model Tag name
    rails g model PostTag post:references tag:references

    class Post < ApplicationRecord
      has_many :comments
      has_many :post_tags
      has_many :tags, through: :post_tags
    end

    class Tag < ApplicationRecord
      has_many :post_tags
      has_many :posts, through: :post_tags
    end

from there it's just regular rails:

    Tag.find_by(name: "something").posts
    Post.joins(:tags).where(tags: { name: "something" })
    Tag.create(name: "something")
    Post.create(...)
    Tag.first.posts << Post.all.sample(2)

made a little repo if people want to play with it: https://github.com/localhostdotdev/bug/tree/orm-or-not-orm

[davidcuddeback]

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.

[vinceguidry]

> Not the subsequent years of maintenance.

You're gonna have to pry the Rails from my cold dead fingers if you want me to maintain a web app's database abstraction layer long-term. No other tool works half as well as ActiveRecord. You could maybe convince me to try out https://rom-rb.org/ but only on a brand new project and only if Rails isn't appropriate.

If it's a project that wasn't built with Rails, I'm going to want https://github.com/jeremyevans/sequel if ActiveRecord is too much trouble to introduce.

[oogway8020]

I have been lucky to be able to pick what I want to use, so I pick non-rails stack (Sinatra/Padrino and now Roda + Sequel). No other tool works as half as Sequel. You're gonna have to pry Sequel from my cold dead fingers.

[vinceguidry]

Don't get me wrong, I love Sequel. But ActiveRecord is far more polished. And that starts to matter once you start needing to go 'off-script'.

[djupblue]

Adding an index on tags.name is likely not very useful on its own but adding an index with an uniqueness constraint to prevent duplicates is probably a good idea. Assuming there are just a few different tags records (<1000) then a sequential scan is generally either insignificantly slower or even faster than an index scan.

>Not the subsequent years of maintenance.

I'd much rather maintain this example than a code base replicating the same behavior without an ORM.

[localhostdotdev]

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...

[davidcuddeback]

> I stayed close to what the author did.

Fair enough. I’ll concede that wasn’t a fair comparison to the OP. My point remains that examples focusing on the initial setup are uninteresting (to me) because that’s not where the bulk of the work is.

[blueplanet200]

Rails is also fine to maintain down the road. Certainly easier than any data layer most engineers would make by hand.