I’m happy to announce that I released Atlas 2.1.0 late yesterday. (Atlas is a data mapper for your persistence model in PHP – not your domain model.)
In addition to some minor added informational and convenience functionality, the big addition in this release is support for many-to-one relationships by reference (aka “polymorphic association”). You can see the documentation for it here.
Atlas uses SQL terms for relationships instead of OOP ones (e.g., “many-to-one” instead of “has one”). As such, the OOP term “polymorphic assocation” just wasn’t a good name for the feature.
However, some research revealed that
Postgres has a
constraint type named
that supports the feature
- https://www.postgresql.org/docs/9.4/static/sql-createtable.html (search for “REFERENCES”)
After trying out several alternative names, “many-to-one by reference” was a much better fit than “polymorphic association.”
Because Atlas is for the persistence model, and not for the domain model, I had to wonder if this kind of behavior belongs in the database work at all. Should it happen in the domain instead?
After working through the problem, the answer turned out to be that it has to go in the database work. You simply don’t know which foreign tables to select from in the first place, without that information being represented in a relationship description. The reference column determines what the foreign table should be. If there are different values in the reference column, then you have to select from different tables to get the related rows. That can’t happen once you’re in the domain layer; it must happen in the persistence layer.
Relationships-by-reference may not be a good data design choice if you are starting from scratch. See this 2009 presentation from Bill Karwin for some other alternatives:
These each have different tradeoffs, and in one case require that your database system supports parent tables.
Of course, if you already have a database design that uses many-to-one relationships by reference, then you’re probably stuck with it. Atlas can now help you out in this situation.
This Reddit comment leads me to understand that I read the
REFERENCES Postgres doc too hastily. In context of the linked mailing
list message, I understood "refcolumn" to be on the native table, not the foreign
one. So it's a standard foreign key constraint, not a specialized/extended form
provided by Postgres; I confess I find it easy to believe that Postgres often
supports things that other databases do not.
You can read the Reddit commentary on this post here.