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

Decouple Command from Relation #605

Open
solnic opened this issue Jun 25, 2020 · 0 comments
Open

Decouple Command from Relation #605

solnic opened this issue Jun 25, 2020 · 0 comments

Comments

@solnic
Copy link
Member

solnic commented Jun 25, 2020

At the moment commands rely on relation objects, which is problematic and makes configuration/setup and other features more complex. The reason why this is done like that is because in the early days relations didn't create commands, commands were completely standalone and they offered features that were partly provided by the relations, like restricting a command through a relation view.

Currently relations produce their own commands but they still inject themselves into the command constructor. This should be simplified by:

  • Commands should receive in its constructor a relation dataset instead of the whole relation
  • In addition to the dataset, commands constructors could receive a relation's mapper so that a command can return results that are mapped in the same way as if you used the relation itself to get results - this will only be needed by non-void commands (void-return commands will be done in 6.0 too, see Command/Query Separation for ROM::Commands #606)
  • Remove method_missing behavior that delegates relation view method calls, ie users.command(:update).by_pk(2).call(name: "Foo") is now possible, but this is redundant since you should be using relation instead: users.by_pk(2).command(:update).call(name: "Foo") - this behavior will be preserved
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant