Flask-SQLAlchemy sets the Session to autoflush=False. That's pretty much the
difference here, and "lazy='dynamic'" works poorly with this setting. There is
sort of a bug-like behavior I can pull out of it here where I see the history
is getting set incorrectly, as I suspected, and I should look into that.
But for now just flushing within the get_or_create() step (or setting
autoflush=True, or not using lazy='dynamic') will resolve this issue:
@classmethod
def get_or_create(cls, trove):
try:
sess.flush()
obj = sess.query(cls).filter_by(trove=trove).one()
except NoResultFound:
obj = cls(trove)
return obj
On Dec 15, 2012, at 11:31 AM, Donald Stufft wrote:
> Fooled around with this some more. And i'm pretty sure it's got to be
> something with Flask-SQLAlchemy now. I spent a few hours futzing with the
> test case and was unable to make it do anything, but as soon as I switched it
> to Flask-SQLAlchemy (https://gist.github.com/7f15df7a2d20d9736fed) The
> IntegrityError came back. So now I have a new place to go bother to figure
> out why :)
>
> On Saturday, December 15, 2012 12:12:26 AM UTC-5, Donald Stufft wrote:
> Ugh nevermind me. It's late and I forgot to name the Index :/
>
> On Saturday, December 15, 2012 12:06:28 AM UTC-5, Donald Stufft wrote:
> So it appears the problem is with UniqueConstraint vs Index(..., unique=True).
>
> Test case: https://gist.github.com/4291461
>
> On Friday, December 14, 2012 11:43:19 PM UTC-5, Michael Bayer wrote:
> its probably some subtlety to the data that's already loaded and how the
> collection is being mutated - it's unlikely Flask has anything to do with it.
> There may or may not be some less-than-ideal or buggy behavior in
> association proxy, or it might be a premature flushing issue, but if you can
> come up with how to reproduce that would be very helpful.
>
>
> On Dec 14, 2012, at 11:38 PM, Donald Stufft wrote:
>
>> Hrm. I'll see what I can do. Though looking at what you posted it works for
>> me with that too.. So the problem must either be with Flask-SQLAlchemy or
>> with my own app code.
>>
>> On Friday, December 14, 2012 11:30:57 PM UTC-5, Michael Bayer wrote:
>> I've cobbled together a complete and simplified test case given your mapping
>> and example code and I cannot reproduce with either 0.7 or 0.8 - the count
>> of rows in the association table is one on the first commit, and two on the
>> second.
>>
>> You need to adapt the attached test case into a full reproducing case so
>> that the specific trigger is illustrated...thanks.
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "sqlalchemy" group.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msg/sqlalchemy/-/Xn2eZ0gifLgJ.
>> To post to this group, send email to sqlal...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> sqlalchemy+...@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 view this discussion on the web visit
> https://groups.google.com/d/msg/sqlalchemy/-/w7AbNMBU6VIJ.
> 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.
