I stick with autoflush=True, and flask probably shouldn't make a decision here. 
 But there really shouldn't be any major behavioral changes with 
autoflush=False other than data stays pending longer, so dynamic here 
definitely needs some fixes.


On Dec 16, 2012, at 2:53 PM, Donald Stufft wrote:

> Hey thanks a ton!
> 
> Looking at the Flask-SQLAlchemy history, it seems autoflush=False has been 
> the Flask-SQLAlchemy default since the initial checkin. Not being all that 
> educated on when you'd want false/true is there any good reason for me to not 
> just restore the SQLAlchemy default of autoflush=True?
> On Sunday, December 16, 2012 at 2:12 PM, Michael Bayer wrote:
> 
>> 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.
> 
> 
> -- 
> 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.

Reply via email to