Optional more explicit relations
There are times that it would be nice to be able to define a relationship more explicitly. Currently you define a bidirectional relationship using the backref option in the call to relation(). This is convenient but you are defining functionality for one object in a totally different set of objects. So it would be nice to be able to have something like an inverse attribute to a relation that you could use to tie the two relations together.
So taking from the One to Many example from the docs, instead of:
mapper(Parent, parent_table, properties={ 'children':relation(Child, backref='parent') })
mapper(Child, child_table)
It could optionally look like:
mapper(Parent, parent_table, properties={ 'children':relation(Child, inverse='parent') })
mapper(Child, child_table, properties={ 'parent':relation(Parent, inverse='parent') })
Of course this is just off of the top of my head, so feel free to make any changes to make it more in line with SA conventions :)
Comments (9)
-
Account Deleted -
Account Deleted (original author: ged) For what it's worth, what the original poster asked is supported in Elixir (and is the recommended way to declare bidirectional relationships in Elixir).
-
Also, the intent is to be able to keep the information in the mapping. The impetus behind this was that mappings were being stored in separate files, and the user wanted to be able to determine all the relationships that each mapping pointed to without hunting through other files/mappings for backrefs.
(From the channel)
-
repo owner this is hibernate's method also. so heres the questions.
-
how do we avoid TMTOWDTI ?
-
more specifically to 1., how do we document ? here's backrefs, oh but by the way you can do it this way too ? or just we rely on the "inverse" option being referenced in the docstrings, most SA users aren't aware of it, elixir's life gets easier by using this feature, and we're done ?
-
do we implement full backref behavior here ? i.e. the AttributeExtensions which are maintaining bi-directional state, would they get installed here as they do with backref ?
-
do we implement inverse as the base functionality then maybe rejigger backref() to build on top of "inverse" ? (probably)
i need answers to
#2
and#3
, then we can implement. -
-
Account Deleted -
As discussed on IRC, I'm fine with having it as a keyword available, documented in the docstring only.
-
See answer to
#1. But yeah just make it available to make some of our lives' easier :) -
I would like full backref behavior.
-
That sounds reasonable to me.
-
-
repo owner - changed milestone to 0.5.xx
-
repo owner initial version of this is mostly implemented in a dev branch in c56c1b61ccdddb09217c3d7354a3649b240c0cac. not decided if this will be for 0.5.0 or not.
-
repo owner - changed status to resolved
implemented in 209e888e1bda69924b364ae3394016acef0e9d41.
-
repo owner - removed milestone
Removing milestone: 0.5.xx (automated comment)
- Log in to comment
one more possible option: have the relation declared once (and not twice as above), but separately from any of the sides. e.g.
class Child...
class Parent...
relate( Child, 'parent', Parent, 'children', 1toMany)
sdobrev