Background:
(1) I use mysql workbench to design my database.
(2) Then I use "Synchronize Model" tool in mysql workbench to apply my modification to mysql database.
(3) Finally I use symfony doctrine:build-schema command to generate schema.yml according to database(For some legacy reason, I have to use Symfony 1.4).
Here comes the problem: I wanna add actAs: { Timestampable: ~ } to schema.yml, but symfony doctrine:build-schema command cannot do that.
The solution I can imagine is to write a shell to edit schema.yml. Clearly this is not an elegant solution.
Any suggestion is greatly appreciated.
1) What errors is given out by command symfony doctrine:build-schema
2) Try such code in schema.yml
Something:
actAs:
Timestampable:
columns:
...
I use MySQL Workbench Schema Exporter (an open source PHP library project) to save time and complete all database model definition tasks in modeling process. Review this Installation Tutorial.
With MySQL Workbench Schema Exporter you can use Table Comments to define table behavior. To add a timestampable behavior to table definition put this in your comments:
{MwbExporter:actAs}actAs: [Timestampable]{/MwbExporter:actAs}
Then export your model (*.mwb file) to YAML (*.yml file) using MySQL Workbench Schema Exporter and place it in ./config/schema/ folder in order to create an sql script and then load it to a database already configured with symfony. It's easy! just like this:
Export model to YAML
php bin/mysql-workbench-schema-export your_model.mwb
Copy schema.yml resulting file to ./config/schema folder location
Create an sql script
php symfony doctrine:build-sql
Now build your model physically with:
php symfony doctrine:build-model
Related
After creating an Entity and Repository from an existing pre-doctrine database, I am unable to make an initial migration. It gave me this error [ERROR] The version "latest" couldn't be reached, there are no registered migrations. Any idea how to do an initial migration without starting fresh? And for some reason, the migration folder exists outside the src folder, why is it so? In a previous project, the migration folder exists inside the src folder.
Any insight would be appreciated. Thank you for reading.
EDIT: doctrine_migrations.yaml:
doctrine_migrations:
migrations_paths:
# namespace is arbitrary but should be different from App\Migrations
# as migrations classes should NOT be autoloaded
'DoctrineMigrations': '%kernel.project_dir%/migrations'
The commands I used to generate the Entity and its Repository is as follows:
php bin/console doctrine:mapping:import "App\Entity" annotation --path=src/Entity
modified the #ORM\Entity => #ORM\Entity(repositoryClass="App\Repository\UserRepository") in the entity .php
php bin/console make:entity --regenerate
Then when I run bin/console doctrine:migrations:migrate, the error pops up.
Work for me
doctrine_migrations:
migrations_paths:
'App\Migrations': '%kernel.project_dir%/src/Migrations'
and use for migration classes
namespace App\Migrations;
THis is my migrations config.You can test it :
doctrine_migrations:
dir_name: '%kernel.project_dir%/src/Migrations'
# namespace is arbitrary but should be different from App\Migrations
# as migrations classes should NOT be autoloaded
namespace: DoctrineMigrations
For migration commande i use : php bin/console d:m:diff and after this you can use the migration number with this commande :
php bin/console d:m:e --up the_migration_number
I tried most of the methods but it seems that it is possible to generate the migration. However, changes to the entity will not be detected by doctrine.
For example, if I change the field of name to username, php bin/console doctrine:migration:diff does not detect the changes.
What I found worked was exporting the database as .sql, creating the entity the normal way, and manually typing in the fields. Delete the generated table in phpmyadmin, and importing the data back in. Only then would it be working as I want it to be.
I get this error when I create a new module:
"Please upgrade your database: Run "bin/magento setup:upgrade" from the Magento root directory.
The following modules are outdated:
Sangeeta_Octan data: current version - none, required version - 0.0.1";i:1;s:1781:"#0
I searched on google and found no solution other than reinstalling Magento. Such as:
version has been changed from "2.0.0.0" to "2.0.0" during development,
so update tool can't recognize that "2.0.0.0" <= "2.0.0". Please,
re-install your application from scratch to get latest version. `
Do I have any options apart from reinstalling?
Change the setup_version of your module (Sangeeta_Octan) in
app/code/Sangeeta/Octan/etc/module.xml. Try a different version
name like setup_version="2.0.1" or setup_version="3.0.0"
Run bin/magento setup:upgrade
If that doesn't work, disable your module by changing your module name in app/etc/config.phpfrom Sangeeta_Octan => 1 to Sangeeta_Octan => 0. Then run bin/magento setup:upgrade
I hope below solution also solve your problem.
https://magento.stackexchange.com/questions/112293/mysql-error-and-possible-duplicates-running-bin-magento-setupupgrade-after-rena/112299#112299
in mysql find the table setup_module It will have 3 fields. Find the NULL values in data_version & have them match the schema_version
As an alternative, you can access your magento database and look at the table setup_module
You will see a list of all installed modules and you can manually set the schema/data version numbers here.
Delete the offending rows from the setup_module table (if they are there) and run the command bin/magento setup:upgrade from your Magento 2 root directory.
This is happens because of something wrong while running "bin/magento setup:upgrade" and the data_version in Module versions registry is null. It is loaded from DB, We can just proceed by manually changing it in db.
Go db via php myadmin and check "setup_module" table, the
data_version which are mentioned "null".
Login to Mysql database => then update table setup_module of the "data_version" column same as "schema_version"
I currently got orm set up on my silex application. Everything seems to work as expected except for when I run the command to generate the entities from my database (reverse-engineering).
../../../vendor/bin/doctrine orm:convert-mapping --namespace="Random\MyApp\Model\Random\Entities" --force --from-database annotation ./../random/entities
This command will create all of my entities perfectly but they will be under the folder structure
./../random/entities/Random/MyApp/Model/Random/Entities/(files here)
which is wrong since I am expecting to have
./../random/entities/(files here)
A namespace is actually the path under your entities are grouped. So it's perfectly logic that doctrine generates files under this namespace.
If you want a file structure like it just do :
../../../vendor/bin/doctrine orm:convert-mapping --namespace="random/entities" --force --from-database annotation ./
But this is definitely not conform with the PSR-0
I have read other posts, when searching, an answer to this question.
I am using PostgreSQL 9.1, and created extension 'citext' using CREATE EXTENSION citext, but when I try to create any columns of type 'citext', it throws this error
ERROR: type "citext" does not exist
I researched but did not find any concrete answers? Any idea why?
Ok figured it out. I have several databases and CREATE EXTENSION citext has to be run for each db to install the extension in that DB. You must do on psql prompt:
psql =# \c db_1
CREATE EXTENSION citext;
psql =# \c db_2
CREATE EXTENSION citext;
#NullException is correct that the extension needs to be created in each database. If you want to automatically have an extension created, you can create it in the template1 database which (by default, at least) is the database used as a model for "create database", so with appropriate permissions, in psql:
\c template1
create extension citext;
Then new databases will include citext by default.
To use citext, use the CITextExtension operation to setup the citext extension in PostgreSQL before the first CreateModel migration operation.
https://docs.djangoproject.com/en/2.2/ref/contrib/postgres/fields/#citext-fields
from django.contrib.postgres.operations import CITextExtension
class Migration(migrations.Migration):
...
operations = [
CITextExtension(),
...
]
similarly to HStoreField as
https://docs.djangoproject.com/en/2.2/ref/contrib/postgres/operations/#create-postgresql-extensions
If you use Docker, and want to add this extension to your database,
I have done the following,
# Dockerfile
FROM postgres:11.3
# Adds the CIText Extension to our database
COPY ./compose/production/postgres/initdb_citext.sh /docker-entrypoint-initdb.d/citext.sh
And my initdb_citext.sh:
#!/bin/sh
# Adds the citext extension to database and test database
"${psql[#]}" <<- 'EOSQL'
CREATE EXTENSION IF NOT EXISTS citext;
\c template1
CREATE EXTENSION IF NOT EXISTS citext;
EOSQL
This applies the extension to test databases that django generates too.
I am using Symfony-2.0 and Propel 1.6.
For testing purposes I'd like to have separate schema file. The reason is that with my current schema it is impossible to load dumped fixtures, because process fails due PK and autoincrement:
app/console propel:fixtures:load --env=test
Use connection named default in test environment.
No SQL fixtures found.
No XML fixtures found.
[Propel] Exception
Cannot insert a value for auto-increment primary key (article.ID)
If I could define test_schema.xml I'd generate models from it without autoIncrement="true" property and then fixtures would be loaded.
How can I force Propel to use test_schema.xml in test environment?
Or may be there is another way how to load fixtures correctly?
You can use the propel propel.schema.dir and propel.default.schema.basename build properties to specify where the schema file is located and its name:
# app/config/config_test.yml
propel:
build_properties:
# The directory where Propel expects to find your `schema.xml` file.
propel.schema.dir = //wherever
# The schema base name
propel.default.schema.basename = schema