Thank you, Mike!

the above table is relationally incorrect - you should never have 
> duplicate data inside of a table like that, and the student_id and 
> instructor_id columns should normally form the primary key, or at 
> least a unique constraint of some kind.

I agree. I didn’t want to add constraints yet because I wanted to see if 
the duplication could be solved in another way (e.g. an INSERT … IF NOT 

> But beyond that, is a 
> "favorite" inherently bidirectional?   usually "favorites" have a 
> direction,   A might be B's favorite, but B is not A's favorite. 

As for the “favorite” relationship, well, in this case it’s an implied 
bi-directional one…

> if you *do* want to add on both ends but it's "unique" anyway, try 
> using collection_class=set with your relationship.  that will 
> eliminate dupes on the Python side and you can set up the table rows 
> as unique.

Ah, nice: documentation in section Customizing Collection Access 
The “favs” are now an InstrumentedSet 
of a standard Python list but I guess that is alright. Adding and deleting 
worked using sets.

The one thing I noticed, however, was that I have to use back_populates 
on both sides (to get the set on both sides) instead of backref 
just one (to get a set on the defining side and default list on the backref 


SQLAlchemy - 
The Python SQL Toolkit and Object Relational Mapper

To post example code, please provide an MCVE: Minimal, Complete, and Verifiable 
Example.  See for a full description.
You received this message because you are subscribed to the Google Groups 
"sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
To post to this group, send email to
Visit this group at
For more options, visit

Reply via email to