Open rubnov opened 5 years ago
Sounds more like a Django issue, no?
Not really. Django's manage.py migrate
runs these migrations correctly and produces the correct OrderItem
table structure in the main db. This issue only occurs in the test db, which is generated by pytest on every test run.
Yeah, but we're calling/using only Django's methods there (IIRC).
Does manage.py migrate
work on a new DB?
I ended up invoking py.test with --nomigrations
flag in order to work around this issue.
same error message
return self.cursor.execute(sql, params)
django.db.utils.DataError: invalid input syntax for type double precision: "no"
@rubnov If you add a print or breakpoint()
call in your rebuild_fk_order_item
function in the migration, does it get triggered? Trying to understand if the migration runs at all or not.
@bluetech no I did not try to debug this. I found a workaround and had other priorities. It should be easy to create a test case on pytest
for this. I think you should be able to reproduce this issue.
After upgrading our Django project from Django 1.11.8 to 2.2.6, along with pytest (from 2.9.2 to 5.2.0) and pytest-django (3.1.2 to 3.5.1), we started getting the following error in some of our test cases:
This is the offending code:
The
DataError
exception is thrown when attempting to create a newOrderItem
which has a ForeignKey toOrder
. The primary key ofOrder
isbraintree_transaction_id
which is a CharField. However,Order
was initially created withid
(integer) as the pkey, which was removed and replaced by varcharbraintree_transaction_id
as the pkey. This was done in a migration.Model classes:
Initial
Order
andOrderItem
migrations:A following migration then alters the primary key of
Order
and remaps the ForeignKey from OrderItem:These are the SQL statements generated by pystest when creating the database (I've included only the
OrderItem
andOrder
model statements):Notice this statement:
CREATE TABLE "premium_orderitem" (... "order_id" integer NOT NULL,...
whereorder_id
ForeignKey is created as integer, which is according to the initial migration, but there is no statement that updatesorder_id
to varchar, only one that updates the REFERENCE topremium_order
. The ForeignKey type remains integer and is never changed to varchar (though it references a varchar field inpremium_order
). This results in a "broken" table structure. Here ispremium_orderitem
table in the test db:Table structure of
Order
is:The primary key appears to be correct:
braintree_transaction_id
and it's a varchar.Somehow the second migration, which updates
Order
's pkey, is not processed correctly andOrderItem
ForeignKey toOrder
remains an integer. This raises an exception when trying to insert new OrderItem with a stringorder_id
to the db (the string refers tobraintree_transaction_id
which is the pkey ofOrder
).When running pytest with --nomigrations option, the CREATE TABLE is done correctly (i.e. ForeignKey is a varchar) and no exception is thrown when creating new OrderItem.
Has anyone encountered this issue before?