I mistakenly used a mysql reserved keyword 'condition' when defining my model(yml). I then renamed the field to 'description' and generated entities but cannot run the command php app/console doctrine:schema:update because the generated query ALTER TABLE segment_filters CHANGE condition description VARCHAR(300) NOT NULL contains the keyword.
I have tried the following:
renaming field directly on the database(desparation)
clearing cache php app/console cache:clear
clearing various doctrine caches doctrine:cache:clear-* -flush (with and without flush)
I have tried googling and reading but maybe it's one of those days that the head just needs a break. Any help will be heavily appreciated
I have faced a similar issue before. This is related to mysql syntax. Symfony2 reverse engineering will help you resolve this issue
Change the col name directly on the database table.
run php app/console doctrine:mapping:import --force Bundlename format(yml/xml/php).
This will map your doctrine yml's for that bundle with the database
run doctrine:generate:entities on that bundle.
Mission accomplished.
Related
I am running sonata admin and I have an existing working entity/admin. I've added another 2 columns to the doctrine orm, the entity, the admin and ran the app/console doctrine:schema:update commands to get the fields in to the database successfully.
On local dev environment, this works great.
On production, the new fields aren't saving.
When saving the entity within sonata admin if I manually call $this->isMyNewField() in preUpdate or postUpdate I get the correct result of true or false depending on whether i checked the box or not.
However doctrine doesn't seem to be correctly registering the field at all, i've logged the sql that it is running on update and persist and it literally doesn't even try and do anything with the field whatsoever on either.
If I change the AppKernel to run on 'dev' rather than 'prod' (on production environment) then all works as expected and doctrine picks it up without an issue.
Ive tried clearing doctrine metadata, clearing cache, restarting servers, changing field types, removing in doctrine and re-adding (via the entity orm xml file)
Still no luck. Any other ideas I can try?
Thanks
Kevin
Hi all turns out it was the command
app/console doctrine:cache:clear-metadata
That needed running, I had tried this without success so the big thing I missed off it was the env so the command was
app/console doctrine:cache:clear-metadata --env=prod
Was fine after this, very frustrating
I have just discovered the ORM\Index annotation and have gone through my entities to add in all the indexes I should have on my tables.
But I now don't know how to apply these changes to my database.
I tried doctrine:migrations:diff but it didn't pick up the changes.
Is there any other commands that I can use (without rebuilding the database) or will I have to apply all the indexes manually in mysql?
edit: I was being stupid. The indexes I added to test were on ManyToOne fields, which already get indexes. I've added an index to one of my data fields and migrate picked it up.
doctrine:schema:update --dump-sql
will give you a list of all the mysql changes that will occur.
doctrine:schema:update --force
will apply those updates for you (do not do this on production)
I have some beginners questions regarding Symfony 2 which I cannot get clear answers for from previous questions (perhaps because they are genuinely basic)
When you create a new symfony2 project from the command line and specific the database name and passwords, is this meant to automatically create the database (which you can see in phpmyadmin) or does one manually do this.
Following from this, if one creates a number of entities and then uses
doctrine:schema:update
Should the specified tables be automatically created in the database you have specified in the projects "parameters.yml" file.
I have performed "doctrine:schema:update --force" which then gave me
Updating database schema...
Database schema updated successfully! "2" queries were executed
But no tables were created. So I tried again, to see what the message would be...
unknown-ec:35:86:4d:41:5e:symfony simonalice$ php app/console doctrine:schema:update --force
Nothing to update - your database is already in sync with the current entity metadata.
unknown-ec:35:86:4d:41:5e:symfony simonalice$
So clearly Doctrine thinks its in synch - but no tables in phpmyadmin.
Clearly complete beginners stuff....but I would be grateful for some steerage on this from a Symfony 2 veteran.
To answer your questions:
No, creating a new Symfony project will not create your database (or the user connecting to it). You still need to do that and I would recommend you create a dedicated user for your application with suitable permissions. You'll need to use a database user with administrative privileges to do this. For security reasons, it's best to not use your database administrator account with your application. To instruct doctrine to create your database (once you have your db user and connection parameters set), you can run the php app/console doctrine:database:create console command.
Yes, running the doctrine:schema:update console command will generate your database entities, but it won't/can't create your database. You can also use the --force option to apply changes you've made since the last update. These updates will still be bound by any column constraints you've defined, so if for example you change an existing nullable column to not null, you'll get an error if records already exist with null values.
Hope that helps.
Sorry if the question is one of a newb.
When I deliver my symfony2 website to my production webserver. I'm using a low cost hosting service. I cannot access mysql remotely ( only execute statement from their website through phpmyadmin ).
Case 1: Assuming I could access remotely, i should run:
php app/console doctrine:schema:create --env=prod
with appropriate database settings so it would update my db.
Case 2: Assuming I can't access remotely, then i have two option:
I could create an ugly script that would call the above line from the website and remove it after delivery.
I could get the sql statement printed to a file and execute it. Which seems better to me.
Question:
Is there a pb with the above ?
Is there a way to get an sql script in a file from:
php app/console doctrine:schema:create --env=prod
You can dump the sql statement using the --dump-sql option, and store it in a file:
php app/console doctrine:schema:create --dump-sql > statement.sql
i have generated some tables from entities using the :
php app/console generate:doctrine:entity
php app/console doctrine:schema:update --dump-sql
php app/console doctrine:schema:update --force
where can i find the generated schema file , describing all the table and fields that has been generated?
What's the best procedure to remove entities and table ?
php app/console doctrine:schema:update --dump-sql dumps the sql generated and executed in the command prompt, there is are no files generated with this command (asfar as I know).
A Doctrine table in the database should be seen as a collection of objects, if you want the table removed, remove the entity that holds the data and use the command php app/console doctrine:schema:update --force.
If you want to change fields in the table, change the fields in the entity class holding the data and again use php app/console doctrine:schema:update --force