I'm not all that familar with SQLA internals. But here's something
interesting.
>>> import test
>>> test.v.classifiers = [u"Foo"]
2012-12-14 23:53:15,291 INFO sqlalchemy.engine.base.Engine DELETE FROM
version_classifiers WHERE version_classifiers.classifier_id = ? AND
version_classifiers.version_id = ?
2012-12-14 23:53:15,291 INFO sqlalchemy.engine.base.Engine ((1, 1), (2, 1))
2012-12-14 23:53:15,291 INFO sqlalchemy.engine.base.Engine SELECT
classifiers.id AS classifiers_id, classifiers.trove AS classifiers_trove
FROM classifiers
WHERE classifiers.trove = ?
2012-12-14 23:53:15,291 INFO sqlalchemy.engine.base.Engine (u'Foo',)
>>> from warehouse.models import Version
>>> v = Version.query.first()
>>> v.classifiers = [u"Foo"]
2012-12-14 23:55:00,951 INFO sqlalchemy.engine.base.Engine SELECT
classifiers.id AS classifiers_id, classifiers.trove AS classifiers_trove
FROM classifiers
WHERE classifiers.trove = %(trove_1)s
2012-12-14 23:55:00,951 INFO sqlalchemy.engine.base.Engine {'trove_1':
u'Foo'}
Notice how the test code is executing a delete statement beforehand while
my app's copy is only selecting the classifier.
On Friday, December 14, 2012 11:52:21 PM UTC-5, Donald Stufft wrote:
>
> Ok, so what I've got so far. I believe it's related to the
> association_proxy as (Using my application code, not the test case):
>
> v = Version.query.first()
> v._classifiers = [Classifier.get_or_create(u"Foo")]
> db.session.commit()
> v._classifiers = [Classifier.get_or_create(u"Foo"),
> Classifier.get_or_create(u"Bar")]
> db.session.commit()
>
> Works, but if I then do:
>
> v.classifiers = [u"Foo"]
> db.session.commit()
>
> I get IntegrityError: (IntegrityError) duplicate key value violates unique
> constraint "idx_version_classifiers"
>
> So now i'm seeing what I can do with the test case you sent me to get it
> to exhibit the same behaviors :)
>
>
> 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/-/a3La-4PHFjIJ.
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.
