Creating ApplicationModel

[wangjohn]

This PR creates the ApplicationModel class. This class will serve as an intermediate between a model and ActiveRecord::Base. Currently, to create a model, one follows the following procedure:

class MyModelName < ActiveRecord::Base
end

This inherits directly from ActiveRecord::Base and means that all configurations on ActiveRecord::Base are global to all of its subclasses (unless the subclass redefines the configuration on its own).

I'm introducing ApplicationModel so that models have an intermediary layer for inheritance like so:

class MyModelName < ApplicationModel
end

What the ApplicationModel class does is allow different sets of configurations to be defined on multiple applications. Each Rails application will have its own ApplicationModel. The ApplicationModel figures out which application it belongs when it is pulled in through the railtie and configs_from is specified.

\cc @spastorino, @josevalim Can you guys take a look? I'm sure there's something I forgot so please let me know.

[robin850]

Awesome pull request, thank you! I've noticed several things:

• I think that the main README file should be updated since it states that models derived from ActiveRecord::Base, this is still true but not completely. The RDOC_MAIN.rdoc files should be updated as well in each project.
• All the guides should be updated (mainly all the ActiveRecord ones and "Getting started with Rails"). Also, I think that we should mention the motivation behind the existence of this new class in the "Active Record Basics" guide.

Don't hesitate to ping me if you want some help. 😃 Thank you!

[egilburg]

Thanks! Given the very large scope of this PR could this be a right time to discuss extension vs composition?

I've seen some feedback of people discussing that directly subclassing from ActiveRecord::Base goes counter to Domain-Driven Design, under which class hierarchy should be driven by the problem domain rather than technical implementation. Under this school of thought, the following would be preferable:

class Person
  # Person is the root object under the problem domain.
  # The fact it uses AR::Base as a persistence implementation, shouldn't drive the domain class hierarchy.
  include ActiveRecord::Base # Or ApplicationModel
end

class Client < Person
  # Client is a domain-driven subclass of Person, so it makes sense for it to be an actual subclass
end

The above would also make it more flexible to use include statements either before or after including ActiveRecord::Base (or ApplicationModel), for more granular control over inclusion order and module hierarchy.

This change going to be a disruptive change to matter what, so it's a good time as any to discuss what's the best approach. Thanks again!

[egilburg]

Should base model classes be generated per namespace? E.g.

module TestApp
  class AppicationModel < ::ApplicationModel
  end
end

module TestApp
  class Account < ApplicationModel
  end
end

Anyone remembers how controller generators work for namespaced controllers?

[robin850]

👍 Good point @egilburg!

[wangjohn]

Yep, you're right about this. I'll make the change.

[rafaelfranca]

We already had this discussion in rails 4 and the conclusion was: there are
no real gain other than theoretical thought.

Also include also means inheritance in Ruby, so this change is not worth of
all the the complexity of maintaining the code for support both way
On Sep 8, 2013 3:42 PM, "Eugene Gilburg" notifications@github.com wrote:

Thanks! Given the very large scope of this PR, could this be a right time
to discuss extension vs composition?

I've seen some feedback of people discussing that directly subclassing
from AR::Base goes counter to domain-driven design, under which class
hierarchy should be driven by the problem domain rather than technical
implementation. Under this school of thought, the following would be
preferable:

class Person

Person is the root object under the problem domain.

The fact it uses AR::Base as a persistence implementation, shouldn't drive the domain class hierarchy.

include ActiveRecord::Base # Or ApplicationModelend
class Client < Person

Client is a domain-driven subclass of Person, so it makes sense for it to be an actual subclassend

The above would also make it more flexible to use include statements
either before or after including ActiveRecord::Base (or ApplicationModel),
for more granular control over inclusion order and module hierarchy.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/12162#issuecomment-24026590
.

[egilburg]

What impact will there be on Rails Engines? Will there be a separate ApplicationModel per engine?

[fxn]

I am 👎 on this one, because ApplicationModel would take over a name whose scope is broader than what it means, because not every model is persisted.

[guilleiguaran]

@fxn maybe this should be named ApplicationRecord ?

[fxn]

@guilleiguaran yeah, I believe ApplicationRecord is a better name.

[yfeldblum]

+1 on ApplicationRecord rather than ApplicationModel.

[thegrubbsian]

+1 on ApplicationRecord, but I'm also +1 on doing this as an included module.

[guilleiguaran]

-1 about included module. See 9e4c41c for reason

[wangjohn]

So it seems that most people think it should be called ApplicationRecord, I'll go ahead and make that change. I'll also be starting to slowly change the rdocs and the guides. Thanks everyone for all of the comments/suggestions!

[spastorino]

we agreed with @wangjohn to move his GSoC PRs to this branch https://github.com/rails/rails/tree/rework_initialization