Updating an Entity with New Fields

Hey Teo

Nope, that's because of the convention being followed by Doctrine, you can choose the "underscore" or "camelcase" strategy, or create your own strategy. You can check the full config list here: https://symfony.com/doc/cur...

Cheers!

Hey Dung L. !

> so my question is how can we remove a property, change/update/add a relation of an property using "php bin/console make:entity".
> I know we can edit directly and manually from the Entity.php file but I prefer using the make command.

As you guessed, it's not possible with the make:entity command. I created this command... and it was a TON of work. What you're asking about... *might* be possible... but it also might be unreliable - e.g. what if you tell the command to remove a field called "name" but you've also added a custom method beyond just getName() and setName() like getFullName() which uses this property. Should the command remove that custom method? It's tricky... which is a big reason why it's not implemented.

So, sorry I can't give you the answer you want - but I hope this is a small detail ultimately :).

Cheers!

Thanks for sharing your insight, I do not want to miss the goodness offered by Symfony, at the very least I feel good that something is not only tricky for me but for you too :) - JK!

Hey Dung L.

You only have to tweak your ORM config. It should use the "underscore" naming strategy instead of camel case.

// config/packages/doctrine.yaml

doctrine:
    orm:
        naming_strategy: doctrine.orm.naming_strategy.underscore

Cheers!

Hi MolloKhan ,
what is the annotation

(name="total_point",

can I remove it completely or it needs to be there to reference field "total_point" in the database?
Best regards,

I believe you don't need to specify the table name anymore but you can leave it as a future reference

Got that, Merry Christmas MolloKhan !

Merry Christmas to you too! (A bit late :p)

Thank you anyways, I found the answer to my question here https://www.doctrine-projec... so it is within doctrine document.

Hey Dung,

Glad you figured it out yourself! And thanks for sharing the link with others, might be useful

Cheers!

Hey Stranger

Do you have Symfony plugin installed and configured?

Cheers!

Hmm created new project from that files... and now it suggests.... strange bug... thanks anyway!

Stranger

Great that it's solved now, There are sometimes issues with suggestions, most of time it's because of phpstorm caches, if you face with this problem again, try to invalidate caches and restart PHPStorm

Cheers!

Yes of cause... everywhere it works... for example it suggests |ago , but it doesn't suggest article object :(

Hey Stranger

I'm so sorry for so late answer, but honestly I can't say exactly why it's so. Probably it's related to PHPStorm configuration, the best I can advice for you is to re-check every option from PHPStorm preferences > Languages & Frameworks > PHP > Symfony and after it Invalidate caches and restart

Cheers!

Stranger
-try to debug it here is the code taken from https://symfony.com/doc/4.1...

{# templates/article/recent_list.html.twig #}
{# the contents of this variable are sent to the Web Debug Toolbar #}
{% dump articles %}

{% for article in articles %}
{# the contents of this variable are displayed on the web page #}
{{ dump(article) }}

{{ article.title }}

{% endfor %}

-make sure you see what/data you expect to be suggested!
-if you do not see what/data you expected check your Entity/Article.php and make sure they are properly generated!

Hey Dung L.

Whenever you create a migration via doctrine or a maker command it will synchronize your current database schema to your application (entities metadata). I believe your database schema was just not in sync. There is a command for checking it php bin/console doctrine:schema:validate

Cheers!

Hi MolloKhan , sorry I just figured out how to find this conversation using Disqus, never knew that before. After I ran the command:

php bin/console doctrine:schema:validate
Mapping
-------
[OK] The mapping files are correct.
Database
--------
[ERROR] The database schema is not in sync with the current mapping file.

Can you please suggest me what I need to do properly, I would like to correct this error before my project goes too far.

Thanks Diego!

Hey Dung! If you feel lost among all the changes that you have made to your schema. What I usually do is to commit everything, go to the master branch, re-create the database (drop, create, create schema), then go back to my deving-branch and just run bin/console doctrine:migration:diff. By doing so, you end up with one migration file containing all the difference between master and your branch

I hope this helps. Cheers!

Hi MolloKhan , I understand your suggestion, its clean and straight forward. Unfortunately, my story is a bit different. I started out the project with database creation first! I built the database populate with data then create and connect an application to it. Now, I know I should have populated the db tables in schema using Doctrine:schema:update within Symfony.

So now I am well into the project, and trying to make:entity, then make:migration, then doctrine:migrations;migrate - this is where I am standing, i got me to this trouble.

I do not know if you can still give me advice to get me back on track so that I can migrate from Symfony's doctrine. But I will try to back up my database then drop/create and re-generate the database with my current Entities and doctrine annotation to see if that will reset me to a clean working and proper doctrine/entity migration capability.

I will update this thread after I try. Thanks Diego!

Hello Dung L. , Good news! Thinking of your suggestion, I thought I could apply it in my circumstance, so i backed up code as well database just in case things go wrong. Then I create a new empty schema (no tables yet) pointed my application to the new schema, removed all Versions.php under Migrations directory, cleaned out cache, then php bin/console doctrine:schema:validate, sure it is not in sync ([ERROR] The database schema is not in sync with the current mapping file.) Now I ran "php bin/console make:entity --regenerate" then " php bin/console doctrine:schema:update --dump-sql" to review only, then "php bin/console doctrine:schema:update --force" then "php bin/console make:migration" then "php bin/console doctrine:migrations:migrate" --- Surprisingly things went with out error :). And now I have a clean and tight app entities and dbase. Gotta love Symfony and Doctrine. Thank you as usual!

The database tables were created, in mysql the keys, indices, and foreign keys were not named the same as I had before because they are auto-generated by doctrine in Symfony, but that s not issue rather nicety.

That's great! If you have differences in your table and column names, you can always specify their names manually. e.g.

/**
 * @ORM\Table(name="orders")
 */
class Order 
{
    /**
     * @ORM\Column(name="order_id", type="string")
     */
    private $orderId;
}

Thank you MolloKhan , got that!

Hey Yaroslav Y.

You're right but it was done in this way for simplicity/teaching reasons. The bundle VichUploaderBundle is very good at it, if you ever have to upload files, you may want to give it a try

Cheers!

I've just run composer:update and all is now good.

Hey Steve,

Glad you got it working yourself! It was an easy fix ;)

Cheers!

Hey Skylar!

Ah, great question :). So, it is less magic than you might be thinking. First, here is some FULL information about what the asset function does in Symfony: https://knpuniversity.com/s...

Now, here is the shorter explanation: the asset() function ALWAYS adds a slash at the beginning. It doesn't know/care if the file exists - it doesn't do any checks for that. It just adds the slash in all cases. Actually, one of the reasons it exists is that, if you deploy your application under a subdirectory - e.g. example.com/my-app, then it will prefix the path with /my-app/. So, it *always* adds either an opening slash or the app's subdirectory, automatically. If you check out the HTML of the working version, you should see a slash there too :).

I hope that helps! Cheers!

Hey Petru L.!

Ah, very good catch :). So, it depends. Personally, setting it in PHP is much more important to me: I want my PHP object to have the value that will eventually be stored in the database. To use your example, if you ONLY have the "default": 1, then your object might have a null value for this field in PHP, but suddenly it changes to 1 in the database. That's strange to me.

However, I think the options={"default": 1} can be a useful "extra" thing you can add... if you want to (I don't use this, but I can see why some people do). With this config (in addition to defaulting the value in PHP), you make your database a bit more flexible. For example, if you ever need to manually hack a new row manually via an INSERT query, this default value will be reflected. So, it's up to you - but I don't think options= is a better practice, it's just an extra practice, which can be good, depending on how much you care about the underlying database :).

Cheers!

Hi Petru L.,

just wanted to add some thoughts:

* Doctrine FAQs recommend setting default values using properties: https://www.doctrine-projec...
* Doctrine will not go back to the database after persisting a new object to get the default values
* if you rely on your DB to set default values you cannot create easier, faster tests for your entities (without using the DB)
* there could be problems when default values for e.g. date types are different per DBMS (when your live DBMS is MySQL but your tests run on SQLite for example)
* double check on Doctrine Forms overwriting your default values

Because of these reasons we almost always stick to solely setting defaults in the entities themselves.

EDIT: as this is about adding fields to entities, you might have problems with existing rows for a new column which should be not null and but has no default value...

"as this is about adding fields to entities, you might have problems with existing rows for a new column which should be not null and but has no default value"

Well, for me that's a HUGE problem.

Imagine when you have a project in production and need to add NOT NULL (and no default) field. You cannot just truncate database table. Doctrine migrations become somewhat unusable in this case.

And it's not something special or rare: these kind of fields are actually the most prevalent ones.

Unfortunately I cannot see any reasonable solution rather than manually edit migration files to enter proper default values.

Hey Ivan!

This is precisely what I do in these situations: if your database column is NOT NULL and has no default, then you absolutely need to add some custom code in your migration to handle it - I totally agree this is the correct approach. I usually: create the column but allow NULL, set value on that column for all rows with the next query, and finally use one more ALTER TABLE to make it NOT NULL. Doctrine migrations are great for structure changes - but it can't correctly determine how to handle data in these situations.

Cheers!

Great answer! :)