Thanks for the explanation Mike! Seeing it now, I actually think there’s a
decent reason to want the current backerefs:
My understanding is that with session.merge in SQL Alchemy it’s possible to
draw a very clean line between entities that are persisted (or about to be
persisted on the next
I just tried it again, and it works. Sorry for the confusion. Knowing
myself, I misspelled something when I tried it the first time.
-Lyla
On Sun, Apr 28, 2019 at 9:57 PM Mike Bayer wrote:
> On Sun, Apr 28, 2019 at 9:17 PM wrote:
> >
> > Thanks for the quick responses, and for adding the
On Sun, Apr 28, 2019 at 9:17 PM wrote:
>
> Thanks for the quick responses, and for adding the warning for others!
>
> I tried adding the lines as suggested (
>
> head = relationship("Head", backref="tassel_threads", cascade_backrefs=False)
>
> , but I keep getting the same error.
with the
Thanks for the quick responses, and for adding the warning for others!
I tried adding the lines as suggested (
head = relationship("Head", backref="tassel_threads", cascade_backrefs=False
)
, but I keep getting the same error. I also tried cascade=None, as James
suggested, but that seemed
the next 1.3 release will include a warning for this case, whether or
not the primary key on the transient object is set up or not; it does
a double insert in any case otherwise. It's just when the primary
key is already present, the double insert fails on the primary key
constraint.
Hi there,
I appreciate everyone chiming in to look at this!
However, it's something simple and has to do with one of the API
quirks that we have to decide if we want to keep long term.
Background is at
https://docs.sqlalchemy.org/en/13/orm/cascades.html#backref-cascade.
Basically, when you do
It seems to be related to the cascades happening recursively. The merge
cascade goes from the tassel thread to the head, and then again down from
the head to the tassel thread - which is kind of strange, I would expect
the cascades to only visit each node in the object graph at most once. The
Hi Lyla,
I notice Head.id is defined as String:
> id = Column(String, primary_key=True)
While TasselThread.head_id is defined as Integer:
> head_id = Column(Integer, ForeignKey('head.id'), nullable=False)
Could it be that causes the merge to not recognize the existing instance and a
Hi!
I recently came across some confusing behavior in relations and cascading
using sqllite, and I was hoping that I might get some help explaining what
the behavior is here. I put together a minimum failing script here. I'm
trying to commit one instance of each of two classes, but what ends
