Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ROM::Global => ROM::Environment (multi-env) #288

Merged
merged 8 commits into from Aug 7, 2015

Conversation

Projects
None yet
2 participants
@AMHOL
Copy link
Member

AMHOL commented Jul 17, 2015

This PR removes the auto-registration on inherited hooks and is a step towards removing the ROM global interface, allowing for multi-env and removing a lot of the global state. Auto-registration can still be achieved as @krisleech's wisper broadcasts inherited messages on the relevant class (ROM::Relation, ROM::Mapper, ROM::Command) when inherited.

rom = ROM::Environment.new
rom.setup(:memory)

class Users < ROM::Memory::Relation
  dataset :users
end

class UserMapper < ROM::Mapper
  relation :users
  register_as :entity
  model Struct.new(:id, :name)
  attribute :id
  attribute :name
end

class CreateUser < ROM::Memory::Commands::Create
  relation :users
  register_as :create
  result :one
end

# Define relations/mappers/commands
rom.register_relation(Users)
rom.register_mapper(UserMapper)
rom.register_command(CreateUser)

memory1 = rom.finalize.env

rom = ROM::Environment.new
rom.setup(:memory)

# Define relations/mappers/commands

rom.register_relation(Users)
rom.register_mapper(UserMapper)
rom.register_command(CreateUser)

memory2 = rom.finalize.env

memory1.command(:users).create.call(id: 1, email: 'memory1@memory1.com')
memory2.command(:users).create.call(id: 2, email: 'memory2@memory2.com')
memory1.relation(:users).to_a
# => [{:id=>1, :email=>"memory1@memory1.com"}]
memory2.relation(:users).to_a
# => [{:id=>2, :email=>"memory2@memory2.com"}]

This gives much more freedom to the user as they can create multiple environments which will work completely independently of each other.

Currently the ROM module delegates to an instance ROM::Environment on method_missing for registering relations, mappers and commands - the idea is to add deprecation warnings when this happens to give people time to make the transition.

Without ROM delegating to the environment instance, ROM::Relation[:adapter] and friends will no longer work, as the adapter won't be registered, we could return a wrapper to lazily evaluate this when the class is registered. In addition to this, ROM.register_adapter will no longer be relevant, and it would be down to the user or integration to register the adapter, I like this approach as the user has the freedom to specify the identifier under which the adapter will be registered, but feel free to shout loudly if you disagree.

See also #289, which adds environment plugins, and an auto_register plugin which will register relations, mappers and commands with an environment that it is applied on as they are created.

@solnic solnic added the in progress label Jul 17, 2015

@AMHOL

This comment has been minimized.

Copy link
Member Author

AMHOL commented Jul 19, 2015

Been messing about with this and I think it kills the ROM::Relation[:memory] syntax entirely

@AMHOL

This comment has been minimized.

Copy link
Member Author

AMHOL commented Jul 19, 2015

Alternative would be to keep the adapter and plugin registries global (on the ROM module) and move everything else, or deprecate and get everyone to move to Users < ROM::Memory::Relation syntax

@AMHOL AMHOL force-pushed the feature/remove-rom-global branch from 6e4820b to 3abb487 Jul 19, 2015

AMHOL added some commits Jul 18, 2015

Merge pull request #289 from rom-rb/feature/environment-auto-registra…
…tion-plugin

Add Environment plugins (and auto registration plugin)

@AMHOL AMHOL changed the title [WIP] ROM::Global => ROM::Environment (multi-env) ROM::Global => ROM::Environment (multi-env) Aug 5, 2015

@AMHOL

This comment has been minimized.

Copy link
Member Author

AMHOL commented Aug 5, 2015

This now means people will need to call ROM.use :auto_registration to maintain current interface

@solnic

This comment has been minimized.

Copy link
Member

solnic commented Aug 5, 2015

Trying to wrap my head around those changes. Overall looks like a really cool solution with the plugin.

So, one thing that looks weird is that we have now Environment which is mutable and then it ends up with @env being an instance of Env. Such environments.

I'm wondering how to name those things so it's less confusing. We definitely need an IM, mutable object for gathering components etc. but what we want to end up with is a frozen registry of instantiated components.

@AMHOL

This comment has been minimized.

Copy link
Member Author

AMHOL commented Aug 5, 2015

Yeah, it doesn't really change much, just rather than ROM being a registry for relations, commands and mappers, ROM::Environment is now the registry, ROM::Environment#finalize and ROM::Environment#env just do the same as ROM.finalize and ROM.env before

@solnic

This comment has been minimized.

Copy link
Member

solnic commented Aug 6, 2015

@AMHOL since ROM::Environment is the registry of components (aka relation, mapper and command classes) and ROM::Env is the registry of component objects then I believe we definitely need to come up with better names for those :)

@AMHOL

This comment has been minimized.

Copy link
Member Author

AMHOL commented Aug 7, 2015

I like ROM::Environment personally, it reads well, i.e.

rom = ROM::Environment.new # make a new ROM environment

Agree that ROM::Env could change, sth like ROM::GlobalRegistry or ROM::Container?

@solnic

This comment has been minimized.

Copy link
Member

solnic commented Aug 7, 2015

👍 for ROM::Container

AMHOL and others added some commits Aug 7, 2015

AMHOL added a commit that referenced this pull request Aug 7, 2015

Merge pull request #288 from rom-rb/feature/remove-rom-global
ROM::Global => ROM::Environment (multi-env)

@AMHOL AMHOL merged commit 101a640 into master Aug 7, 2015

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details

@solnic solnic removed the in progress label Aug 7, 2015

@AMHOL AMHOL deleted the feature/remove-rom-global branch Aug 7, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.