Skip to content

Associations Refactor

seancribbs edited this page Apr 18, 2012 · 4 revisions

= Associations Refactor

This is an analysis of the state of associations in Ripple as of April 2012, and a strawman proposal for how to fix them. After discussion of the proposal, the committers will determine whether to include this work in the 1.0 release or to defer it to a later release, or to roll it out in stages.

== Current problems

=== Bad defaults

Links are not sustainable for associations that have larger than a few dozen related documents; furthermore, the reasoning for making links the default is solely historical. Other types of associations have to be created with the :using option, or intuited by the fact that the associated class is an EmbeddedDocument. This is definitely a place where we violate the mantra of "expose the tradeoffs to the developer".

=== Unclear save/validation behavior

For associations between Document classes, the default behavior for whether the assigned target will be saved or validated is unclear. It is also unclear what the default should be. Furthermore, the associated validator is added lazily, leading to surprising behavior in some edge cases.

[#286] [#145]

=== Unclear dependency behavior

People used to ActiveRecord find the lack of the :dependent => [:destroy | :delete] option to be surprising. While I would rather not imply that things can be deterministically deleted in transitive ways (ON DELETE CASCADE is not available), we need something.

=== Too much proxying

Proxies are currently used for one associations, leading to some confusion when the target is nil, but is not falsey. Other frameworks define writer/reader methods on the owner class that differ by association type, whereas Ripple defines a single type of reader/writer that is used regardless of whether the association is singular or plural.

[#197]

=== SRP violations, Too highly factored

There was an impression that we could achieve a lot of code reuse in the association logic by keeping things in separate modules, e.g. One, Linked, etc. This has actually led to too much confusion and complexity; a simpler model would be more maintainable and easier to understand.

== Strawman Proposal