-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
django-spanner's autofield generation does not work for non-default spanner DBs #783
Comments
Fix googleapis#783 Also refactored code a bit such that version detection is no longer used to determine whether BigAutoField exists. BigAutoField exists in Django versions older than 3.0, and the way this is currently monkeypatched prevents us from using any BigAutoField in Spanner with Django 2.2.
Fix googleapis#783 Also refactored code a bit such that version detection is no longer used to determine whether BigAutoField exists. BigAutoField exists in Django versions older than 3.0, and the way this is currently monkeypatched prevents us from using any BigAutoField in Spanner with Django 2.2.
About the next spring a new auto incrementing primary keys features is expected to be released in Spanner. It should make autofield patch unnecessary at all. |
+1. what is current status? But still I'm facing error when migration info is inserted to
On Cloud Spanner, following table is created automatically.
I manually configured
but I'm concerning this is right way for work around. It would be helpful if someone give advice to me and for this workaround. |
Facing this same issue - using spanner as a non-default DB. Whenever I am inserting records to another db - bulk_create is failing with thw following strace
If I remove django_spanner from installed_apps before running this command - it works |
#780 introduced a check as to whether the default database's engine is spanner or not, and depending on that decides to override id generation with clientside uuid or not.
This fix is insufficient. It does improve the situation, as django-spanner will disable its monkeypatches if the default db is not spanner.
But the original issue #742 was talking about using multiple databases, where
default
db is mysql. This is whatdjango.db.connection.settings_dict
refers to. The correct key to check would bedjango.db.connections[???].settings_dict
.Steps to reproduce
django_migrations
table already fail.I'll investigate how to fix. It's likely something else has to be patched entirely.
Environment details
The text was updated successfully, but these errors were encountered: