I can confirm this is a bug as I've found precedent for this not having to
raise, new issue is
https://github.com/sqlalchemy/sqlalchemy/issues/4997
On Fri, Nov 22, 2019, at 9:24 AM, Mike Bayer wrote:
> that said, I'm looking at this as a potential bug because it should be able
> to leave this
that said, I'm looking at this as a potential bug because it should be able to
leave this attribute alone, not really sure how this should be handled.
On Fri, Nov 22, 2019, at 9:21 AM, Mike Bayer wrote:
> lazy="raise" on a many to one is problematic because a lot of many-to-one
> operations invo
lazy="raise" on a many to one is problematic because a lot of many-to-one
operations involve pulling up the object from the identity map, and that's it.
since people are usually only trying to guard against SQL being emitted, use
the raise_on_sql option instead:
parent = relationship(Parent, la
On Oct 18, 2011, at 10:03 AM, fribes wrote:
> Hi all,
>
> Despite some doc and web digging, I didn't find how to tell sqa to behave the
> way I want :
> on deletion on Peripheral, also delete in Actuator.
>
> with the following code, the record in Actuator remains after a deletion, and
> a s
How are you doing the delete?
This should delete both.
a = sess.query(Peripheral).filter(Peripheral.label=='some label').one()
sess.delete(a)
sess.commit()
This will not work.
a = sess.query(Peripheral).filter(Peripheral.label=='some
label').delete()
I think the explanation he
It was in fact a one liner, so you can go back to your original code if you use
the latest 0.6 tip:
http://hg.sqlalchemy.org/sqlalchemy/archive/rel_0_6.tar.gz
thanks for the bug report !
On Dec 15, 2010, at 3:41 PM, Will Weaver wrote:
> Wow, this has been a problem for me for the past 3 or 4
Wow, this has been a problem for me for the past 3 or 4 days and took
a while to get to that example. Defining the backrefs or the
relationships in the opposite direction did the job. I had
intentionally left out some of the backreffed relationships because I
didn't need them for what I was worki
This is an interesting edge case and I can probably ensure that the dependency
between Parent/Child is present in the unit of work even if there is no known
linkage at the Child.parent level for the objects actually present - ticket
#2002 is added for this.
In the meantime, the uow needs to be
