I can't seem to get Flask to migrate my models. I'm following along with the Flask Mega-Tutorial series. At the database setup part of the tutorial, I'm just trying to substitute MySQL for SQLite that is used in the tutorial.
I followed SQLAlchemy's instructions for connecting to a MySQL database, and I've included mysqlclient in my pipfile.
But when I run:
flask db init
flask db migrate
I get the following:
INFO [alembic.runtime.migration] Context impl SQLiteImpl.
INFO [alembic.runtime.migration] Will assume non-transactional DDL.
ERROR [root] Error: Can't locate revision identified by '7bb962b87f19'
I've tried deleting the migrations folder, and I've deleted the environment and recreated to see if that would fix anything. But it keeps saying it can't locate revision. I thought maybe it did something with the database, I've read other solutions saying you have to flush the database. But, there aren't any tables created or any schemas in the database.
Other info:
DATABASE_URL="mysql://root:mypassword#localhost/flask_tutorial"
SQLite database runs fine and makes the migrations. So it must be something I've done with the mysql setup.
Any suggestions or ideas that may lead me in the right direction would be greatly appreciated.
The session was storing incorrect environmental variables exported. Had to completely restart my machine for the settings to reset. I even tried unset for the variables, which didn't remove the variables. Once Flask was able to pick up the correct variable settings for my configuration everything worked as planned.
Please make sure you have used this "SQLALCHEMY_TRACK_MODIFICATIONS= True"
Did you install MySqldb lib. to connect with your mysql db ?
I had the same issue. I had deleted the migrations folder but hadn't done the same for the app.db file. So, every time I tried to create any db migrations, it failed because it was using the old (and still existing) app.db file.
This is how my database was configured:
class Config(object):
# Database configuration
SQLALCHEMY_DATABASE_URI = os.environ.get('DATABASE_URL') or \
'sqlite:///' + os.path.join(basedir, 'app.db')
SQLALCHEMY_TRACK_MODIFICATIONS = False
Deleting the app.db file solved the error. Subsequent db migrations and upgrades worked well.
Related
I am getting an error while running a SQL script to load data. Error is pasted below:
Preparing...
[WinError 32] The process cannot access the file because it is being used by another process: 'C:\\Users\\PRATIK~1\\AppData\\Local\\Temp\\tmpf75l0wi5.cnf'
I have tried uninstalling and installing MySQL several times but nothing is helping.
I faced the same issues while trying to run a MySQL script. I tried to find the process in the temp folder and removed it and tried again but the process seems to start again and appears in the temp folder. I could not run the script, however, I found a workaround, instead of running the script try to open it and run it in the query editor.
Just downgrade your MySQL workbench version.
In my case I downgraded the version from
8.0.25 to 8.0.20.
The sounds like you already had tried that script execution before and stopped it without stopping the mysqld process. So this process (which does the actual import) still holds a file lock on the temporary config file.
Try removing that file and check that all MySQL processes that you don't want are stopped. Then try again.
It seems the actual issue is not related to MySQL itself, but to MySQL Workbench.
The error you're seeing is a generic error coming from Windows itself, not from MySQL. It's unclear how you're running MySQL, for example is it in your localhost, in a Docker environment, or in a remote server.
It seems clear that at least two processes are trying to get an exclusive lock on that temporary file. My guess is that MySQL won't write temporary files to the user folder we're seeing (with your username Pratik).
On Windows, MySQL checks in order the values of the TMPDIR, TEMP, and TMP environment variables. For the first one found to be set, MySQL uses it and does not check those remaining. If none of TMPDIR, TEMP, or TMP are set, MySQL uses the Windows system default, which is usually C:\windows\temp.
Something you can do is to change your MySQL configuration so it uses a specific Temporary path you'll set, restart MySQL and retry running the query. If you see the error contains your new temporary path you've isolated the issue, it is indeed a MySQL problem. If you keep seeing this path you've isolated the issue to MySQL WorkBench.
An alternative approach would be to run the same query from another MySQL client, for example the command-line client mysql; and see if you're getting the same error.
Probably the simpler approach would be to try the queries with dBeaver, another MySQL client, and use that to isolate the issue to either the MySQL server itself or MySQL WorkBench.
This is a common issue for the upgraded version of MySQL, Try using Open Script instead of Run Script and that seems to clear up the issue.
I've found that it was already reported in the official bug tracker: https://bugs.mysql.com/bug.php?id=104841.
I've just checked, and it's still present in MySQL Workbench 8.0.30.
Work Around
Do not try to open the SQL file from this tool bar:
Go to Server > Data Import:
select import from self-contained file
select your target schema
then start import (bottom right btn)
Use Case: A MySQL instance will be running on production with required databases. I need to configure this running container as a master and spin up one more MySQL instance as a slave.
Challenges: Facing issues in configuring running MySQL instance as a master. The issue is not able to create replication user and not able to append the master/slave configuration to my.cnf file. The reason is,
To create replication user or to execute any custom SQL commands in container, we have to place initdb.sql with required SQL commands inside docker-entrypoint-initdb.d. So when container starting it execute the file present in docker-entrypoint-initdb.d and executes it, if the database had not created, if the database had created already it skips executing this .sql file residing in docker-entrypoint-initdb.d. This is the root for failing to configure master because MySQL is running with databases in production. So I cannot take this solution to configure as MySQL.
After facing this issue we planned to put the configuration SQL commands in .sh and keep in docker-entrypoint-initdb.d and execute them by patching the deployment. In this scenario we are facing some permission issues when executing the .sh files.
I need to configure replication(master-slave) for MySQL instance(s) in kubernetes world. I gone through the lot of posts to understand how to implement this. Nothing worked out as I am expecting and as I explained above. Along with this I found a custom image(bitnami/mysql) which supports setting up the replication, which I don't want use because finally I would not be able to implement this in production env.
So it will be very grateful if anyone helps me by suggesting any approach to solve this problem.
Thank you very much in advance.!!!
I have a problem to export a small database using MySQL Workbench's Data Export function on Windows 10.
Previously I have had no problems exporting and importing databases, although after this happened I have changed the security of the server to legacy to get it working with phpMyAdmin using the MySQL Workbench Installer, which I have been unable to change back as when trying to execute the change I got an error stating the installer was unable to create the temporary user (running this as administrator didn't help).
Since then I have also updated MySQL Workbench, the server, and the rest of the components that were installed with it, which seems to have gotten rid of the MySQL Workbench Installer application, as such i am unable to provide the exact error it gave regarding being unable to create the temporary user.
I'm not 100% sure if the above is relevant to the issue but it does seem like it could be related.
The issue that I'm trying to fix is that MySQL Workbench will not export any (or all of) the databases I have set up to a self contained file. The error I keep getting is below:
09:47:47 Dumping va_form (all tables)
Error executing task [Errno 2] No such file or directory: u'D:\Mike\Desktop\Dump20190226.sql'
09:47:47 Export of D:\Mike\Desktop\Dump20190226.sql has finished
I was previously getting a similar error about access denied, which then lead me to change the default dump directory to my desktop, as I'm only going to need to dump files occasionally and sort and send them elsewhere straight away.
I have also tried disabling column-statistics and lock-tables although this has had no effect.
As you can see, at the start of the directory it's trying to dump to it says "u'D:\\" - I am not sure if this leading u is significant, although it is not there in the directory I have specified to dump the file to.
I'm hoping someone here has some insight into this issue, I have no idea why MySQL Workbench's installer was refusing to make the temporary user (even when being run as administrator) and why I cannot find the installer now, as well as the obvious problem of why MySQL workbench is unable to create the file to dump anywhere on the system.
Thanks very much for your time reading this.
It is probably an issue with a recent update of Windows Defender, not with MySQL.
Try to save your dump to folders located somewhere else than Desktop or Documents (I usually send them directly to a cloud service integrated with my OS). If this works, you just need to add an exception for MySQL in Windows Defender.
Background info:
I am quite beginner with django, better equipped with python and quite beginner in mysql (and thus mariaDB) as well.
I work in Windows 7 environment with the following versions:
django 1.9.1
mariaDB 10.0.20
Python 3.4.4
mysql-connector\Python 2.1.3 for Python 3.4
Goal:
I am trying to build mariaDB database and web based user interface for it with django. I have built the database beforehand in mysql and am now trying to create the django project using this database as legacy database.
Problem:
I have retrieved the models to my django project as follows:
python manage.py inspectdb > models.py
and it worked fine. Checked the models.py, as well, and they seemed as they should.
Now, if I try to migrate to create the tables based on django to my legacy db as follows:
python manage.py migrate
I keep getting plenty of nested errors last one being:
django.db.migrations.exceptions.MigrationsSchemaMissing: Unable to create the django_migrations table (Table 'mydb'.'django_migrations' already exists. Please DISCARD the tablespace before IMPORT.)
I figured the table was left in my database folder from previous attempt, but removing it does not help. Even if I check from the database command prompt that the only tables left are native to my database, this same error message pops up still. At some point I wondered if there is some issue with the connector I am using as it is not the recommended one (mysqlclient).
Somewhere, I found that the migration would not even be required. This would obviously save me, but I have no idea, if that is a solution I can go for. Ideally the database would be managed later online and users with admin accounts could add entries there. Otherwise, however the database should be just returning the data.
EDIT: Fixed the error message the python manage.py inspectdb > models.py line
EDIT 29.1.
Running the migration as:
python manage.py migrate --fake
results in the same error.
The issue persists even after removing the django project and starting it fresh.
EDIT v2 29.1.
There is only one of the required table files for the django_migrations table within the database folder. There should be django_migrations.ibd AND django_migrations.frm. However, after running the migration, there is only one file: django_migrations.ibd.
There was something similar going on here, with different file
mysqldump problems with restore error: 'Please DISCARD the tablespace before IMPORT'. It is well explained in the chosen answer.
I think this is related to my issue, but cannot figure out what could help and what to do with this.
EDIT v3 29.1.
And finally I noticed the file giving the django error. It is django's migration recorder at C:\Python34\lib\site-packages\django\db\migrations\recorder.py on line 59.
def ensure_schema(self):
"""
Ensures the table exists and has the correct schema.
"""
# If the table's there, that's fine - we've never changed its schema
# in the codebase.
if self.Migration._meta.db_table in self.connection.introspection.table_names(self.connection.cursor()):
return
# Make the table
try:
with self.connection.schema_editor() as editor:
editor.create_model(self.Migration)
except DatabaseError as exc:
raise MigrationSchemaMissing("Unable to create the django_migrations table (%s)" % exc)
Where the last line raising the error is the line 59. Funnily, the function should work, if the table exists. Only thing I can come up with (as in my previous edit), is that indeed for some reason the frm-file is not created during the migration process.
Why that happens is way beyond me.
I've been working on making an auto-deployment system to make updating my django site easier, and it mostly works, but right now my database changes are screwy. I have the auto deployment run "makemigrations" "migrate" then "syncdb"
The trouble I have is when I run migrate, it tells me that my table already exists and can't be created. Previous answers have said to run "migrate --fake", but if I do this, it appears to think everything is up to date. The issue then is that I run "makemigrations" or "migrate" and it says no changes detected (even though there is a missing column from my database). I tried to run "sqlall" to figure out what it thinks the database should be, and it tells me that I have pending migrations. So I tried running "migrate" and it said no migrations exist.
How do I manage this? And in the future, what should I do for database migrations to troubleshoot/fix these problems?
Thanks
I fixed the problem. The issue stemmed from a misunderstanding of how Django migrations worked. Also, as per the comments, syncdb is no longer a command in manage.py.
The original issue was that I had been using a different database for deployment and then I switched and my migrations were out of sync from my development database, so I had to clear out both databases and migrations and start over with my data. Then I run makemigrations on my local machine and migrate there (for my dev DB). Then I upload to the server and have the fab script run migrate on the server production DB without calling makemigrations. This seems to have fixed the issue.