What is the best way to reset the database along with the migrations.
Here is what I have tried.
Delete all migrations along with deleting all the database tables.
Then running
php bin/console doctrine:mi:diff
php bin/console doctrine:mi:mi
That does not work.
Try running single version at a time like so
php bin/console doctrine:migrations:migrate 'DoctrineMigrations\Version20200722104913'
I tried this:
php bin/console doctrine:database:drop --force
php bin/console doctrine:database:create
php bin/console doctrine:mi:mi
The Problem (in detail):
Everything I do leads me to the same result.
Doctrine thinks that I still have some tables to generate which are long gone (Not in the Enitity anymore)
That's why I have this error:
An exception occurred while executing 'DROP TABLE
greetings_card_category':
SQLSTATE[42S02]: Base table or view not found: 1051 Unknown table
'symfony.greetings_card_category'
I also get this warning
[WARNING] You have 6 previously executed migrations in the database that are not registered migrations.
In my migrations Directory I only have two migrations:
Version20200722104913.php
Version20200722143619.php
Here is the status if it somehow helps.
bin/console do:mi:status
| Versions | Previous | DoctrineMigrations\Version20200717093052 |
| | Current | DoctrineMigrations\Version20200722150530 |
| | Next | DoctrineMigrations\Version20200722104913 |
| | Latest | DoctrineMigrations\Version20200722143619 |
|--------------------------------------------------------------------------------------------------------
| Migrations | Executed | 6 |
| | Executed Unavailable | 6 |
| | Available | 2 |
| | New | 2
At this point I would really just love to have 1 clean database and 1 migration.
How to achieve this?
Be aware that having one migration script isn't the best way, if you work in a team or if application was already deployed. But, in the case that you are the only one developer or if you want to rebase some commit, you can do it.
If you really want to have only one migration script, here is a solution. But first of all, it is always a bad idea to drop data and table manually because of the migration_table that is used by doctrine. This table contains data used by doctrine to know the current state of your database. So, you drop tables manually, your database will be unsynchronized with the migration table, and your scripts will failed. To avoid your current error, you now have to truncate the migration_table. If it isn't enough, drop migration table, if it isn't enough drop and create the database (for the last time, because below is a solution to avoid this kind of mismatch.
Step1: Downgrade your database via doctrine:migrate
php bin/console doctrine:migrations:migrate first -n
At this step your database is empty. (The tips is the keyword "first")
Step2: Delete (after a backup) all files in the migration directory
Step3: Create a new migration
php bin/console make:migration
(or you can use symfony console doctrine:migrations:diff if you do not use the make-bundle)
Step4: Verify and manually edit the file created if necessary.
Step5: Upgrade your database
php bin/console doctrine:migration:migrate -n
Having one migration it isn't the best way, especially when you work in a team and do some features in different branches. With the one migration, it is easy to mess up and do something wrong like in your case. So it's ok to have many migrations.
What about your error, you can manually edit your migration and fix all errors, then run diff and migrate(if needed), or you can drop your database, remove all migrations and create a new one, and then creates migrations after making changes in code.
Related
How could I drop an exisitng AlloyDB database programatically?
I'd like to run a test suite of our application on AlloyDB. I'm able to connect to the cluster using the proxy. However, when I try to drop database to cleanup the test environment, using code like:
echo "DROP DATABASE IF EXISTS application_test" | psql
I'm getting:
ERROR: syntax error at or near "DROP"
LINE 2: DROP DATABASE IF EXISTS application_test
I'm sure I can connect to the cluster correctly, because I run other queries before this one.
How could I remove an existing database from a script? I can't find a good way to do that in the docs.
To run psql from the CLI you'll want syntax like:
psql -d postgresql://\<user>:\<password>#\<AlloyDB IP>:5432/postgres \
-c "DROP DATABASE IF EXISTS \<dbname>"
I am using apache airflow (v 1.10.2) on Google Cloud Composer, and I would like to view the schema of the airflow database. Where can I find this information?
There are couple of ways I can think of comparing our current design.
External metadata DB. If you can connect to the DB then you can get the schema.
From your UI you can go to Data Profiling and run query against the metadata tables(depends on your database types(mysql or postgres etc) and find the information from there and create a schema diagram.
I hope this helps.
According to the Composer architecture design Cloud SQL is the main place where all the Airflow metadata is stored. However, in order to grant authorization access from client application over the GKE cluster to the database we use Cloud SQL Proxy service. Particularly in Composer environment we can find airflow-sqlproxy* Pod, leveraging connections to Airflow Cloud SQL instance.
Saying this, I believe that it will not make any problem establish connection to the above mentioned Airflow database from any of the GKE cluster workloads(Pods).
For instance, I will perform connection from Airflow worker reaching airflow-sqlproxy-service.default Cloud SQL proxy service and further perform DB discovering via mysql command-line util:
kubectl -it exec $(kubectl get po -l run=airflow-worker -o jsonpath='{.items[0].metadata.name}' \
-n $(kubectl get ns| grep composer*| awk '{print $1}')) -n $(kubectl get ns| grep composer*| awk '{print $1}') \
-c airflow-worker -- mysql -u root -h airflow-sqlproxy-service.default
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql> show databases;
+----------------------------------------+
| Database |
+----------------------------------------+
| information_schema |
| composer-1-8-3-airflow-1-10-3-* |
| mysql |
| performance_schema |
| sys |
+----------------------------------------+
5 rows in set (0.00 sec)
We are using ColdBox 4.3 and are deploying multiple ColdBox applications.
Each application is developed separately with its own Coldbox.cfc config file and its own handlers, models, and views. While they do share some common features, they can not (currently) be run as a single big application run out of the root level of the website.
Our webroot directory looks something like this:
/
/coldbox
/app_1
| Application.cfc
| /coldbox
| /config
| | /Coldbox.cfc
| /handlers
| /models
| {etc}
|
/app_2
| Application.cfc
| /coldbox
| /config
| | /Coldbox.cfc
| /handlers
| /models
| {etc}
|
/app_3
| Application.cfc
{etc}
We have a copy of /coldbox at the root level and a duplicate copy of /coldbox inside each application folder.
If I delete either the root level /coldbox -or- the copy of coldbox inside each application, the application will crash.
How do other developers handle the case of multiple Coldbox applications running on the same webserver???
You need to create a CF mapping that maps /coldbox for each app to wherever ColdBox lives. If all your apps use the same version of ColdBox, then I'd just point them all at the same place. And it doesn't even need to be in the web root. As long as /coldbox resolves to the framework, you'll be fine.
And no another note, if you're on Adobe ColdFusion and hosting more than one app on the same server, you'll want to turn off "Component Cache" in the CF administrator. It will really mess you up.
My Example model used to have a decimal field example_field defined as:
sample_field = models.DecimalField(decimal_places=1, max_digits=3, blank=True, null=True)
I decided to remove this field from Example model and everywhere in the code that I used example_object.example_field. After makemigrations and migrate, everything worked well and I made a pull request to a remote branch.
Then I switched to another local branch and got this error:
OperationalError: (1054, "Unknown column 'example.example_field' in 'field list'")
It makes sense becuase this branch still uses example_object.example_field. However, after the remote branch accepted the pull request. I still got the same error after pulling from the remote branch.
Remote branch was deployed on AWS after accepting the PR. One of the two instances was working fine, but the other one had the same OperationalError.
In either circumstance (AWS or local branch), the first step is to make sure that your updated code is, in fact, deployed on the instance properly.
Navigate to to your project
cd /path/to/django/project
Check the Example class definition in the file:
grep -A20 'class Example\(' models.py
Verify that your field has, in fact, been removed from the code on both instances or your local branch.
Do a global search in your project for use of example_field:
cd /path/to/django/project
find . -name '*.py' | xargs grep -Ri example_field
Remove all pyc files and restart your app server:
cd /path/to/django/project
find . -name '*.pyc' -delete
I use Yeoman to build Ember applications.
I want to duplicate an application (changing the directory and application name (which means changing the name in all Ember views, controllers, etc.).
At the moment I'm doing everything manually, is there a better way of doing this?
There is no built-in tool in Yeoman, but if your app name is unique, you can just replace it in all your files by running something like this:
git ls-files | egrep '\.(js|html)$' | xargs sed -i s/OldAppName/NewAppName/g