It was a typo! :-)
> They keep the two sides of a relationship in sync on the python side.
I was suspecting using backrefs was better and that it would do some
kind of synchronization like that, yeah... But I was hoping that
someone would say "No, it's the same"... Because now I won't sleep
soundly at night until I change all my code... But hey... This is what
learning while coding has :-) I will have to "expunge" my old ideas
from my brain and update my code... I hope I can quickly flush the
changes, though
Thank you!
2011/2/24 Michael Bayer <mike...@zzzcomputing.com>:
>
> On Feb 24, 2011, at 1:20 PM, Hector Blanco wrote:
>
>> Hello everyone...
>>
>> I'd like to know what do you think it's better: Whether using backrefs
>> or "manually" defining the relationships one by one. Are the backrefs
>> useful to code less code or do they have other advantages?
>>
>> I.e.: Let's say I have a User and a UserGroup class with (initially)
>> the relationships defined by hand:
>>
>> class User(declarativeBase):
>> __tablename__ = "users"
>>
>> _id = Column("id", Integer, primary_key=True)
>> _email = Column("email", String(60))
>> _userName = Column("user_name", String(50), unique=True,
>> nullable=False)
>> _password = Column("password", String(64), nullable=False)
>> _userGroupId = Column("user_group_id", Integer,
>> ForeignKey("user_groups.id"))
>>
>> _userGroup = relationship("UserGroup", uselist=False)
>>
>> class UserGroup(declarativeBase):
>> __tablename__ = "user_groups"
>>
>> _id = Column("id", Integer, primary_key=True)
>> _name = Column("name", String(50))
>>
>> _users = relationship("User", order_by=lambda:User.userName,
>> cascade="all, delete", collection_class=set)
>>
>>
>> If, instead, I define that _users (in the UserGroup class) as a backref:
>>
>>
>> class User(declarativeBase):
>> __tablename__ = "users"
>>
>> _id = Column("id", Integer, primary_key=True)
>> _email = Column("email", String(60))
>> _userName = Column("user_name", String(50), unique=True,
>> nullable=False)
>> _password = Column("password", String(64), nullable=False)
>> _userGroupId = Column("user_group_id", Integer,
>> ForeignKey("user_groups.id"))
>>
>>
>> _userGroup = relationship("UserGroup", uselist=False, backref=backref(
>> backref = backref("_users",
>> order_by=lambda:User._userName,
>> cascade="all, delete",
>> collection_class=set
>> )
>> ))
>
> is that correct that there is backref(backref=backref()) up there ? clearly
> that's not how it was intended to be used..... unless its a typo.
>
>>
>> and, at a certain point I want to create a resetUsers() method in the
>> UserGroup class (to empty the "_users" set) I have to add the users in
>> that set to the session first and then reset it:
>>
>> class UserGroup(declarativeBase):
>> # Yadda, yadda yadda
>>
>> def resetUsers(self):
>> Database.Session().add_all(self._users)
>> self._users = set()
>>
>> That doesn't happen with the UserGroup._users being a relationship on
>> its own (not a backref). I can just do self._users = set() and it
>> seems to work fine. The database looks consistent to me, and all that.
>>
>> I'd like to know if I'm missing something, or if using backrefs is
>> better for some reason I don't know yet.
>>
>> Any advice will be deeply appreciated. Thank you in advance.
>
> backref means that there are two relationships() set up that have a
> "back_populates" relationship to each other - you can also configure this as
> two distinct relationships with back_populates:
>
> class A(...):
> bar = relationship("B", back_populates="foo")
>
> class B(...):
> foo = relationship("A", back_populates="bar")
>
>
> This means appending to one results in an append, or set, on the other, and
> vice versa, and similar for removes. They keep the two sides of a
> relationship in sync on the python side. That said it is optional, but if
> you were to mutate both sides, both mutations would have an effect during
> flush.
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "sqlalchemy" group.
> To post to this group, send email to sqlalchemy@googlegroups.com.
> To unsubscribe from this group, send email to
> sqlalchemy+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sqlalchemy?hl=en.
>
>
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com.
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
