The UserInterface Methods (Keep some Blank!)

Hey Zoé!

Hmm, yea - some of the code blocks on this page were out-of-date! Thanks for leaving this comment! In the video, we *only* create an email field (not a username field) and return the email field in getUsername(). I just updated the incorrect code blocks to reflect this. But of course, you can do whatever you want - and your setup is equally valid :).

Cheers!

Yo Matias Rouaux!

Hmm.... Ok, let's check 2 things:

1) If you view the HTML source, do you see your CSS link tags? Or are they missing?

2) If the CSS link tags are there, are you able to open that URL in your browser?

It's definitely weird that it works for index.html.twig, but not here! For sure, the first thing I would have thought of is a missing extends tag... but you already thought of that :).

Cheers!

Oh, and if both of those things look good, could you post your templates - `profile.html.twig` and `base.html.twig`?

Last question.
I need to create a file manager to upload an image or many images to a gallery. I have been looking the "How to Upload Files" Documentation, but i dont know if it's the right service to implement. Do you have any to recommend for that task?

Hey Matias,

Hm, it depends on how you see it, but yes, you're looking in the right direction. You can also take a look at popular bundle which helps with files uploading: https://github.com/dustin10... - it will save you some time on initial stage and allow you to start faster. But probably implementing the way from "How to Upload Files" Documentation will give you more flexible solution, however will take more time for its implementation. So if you're enough VichUploaderBundle functionality - just use the bundle.

Cheers!

Oh.... i have inspected the code like you said and the links where there.. but i forgot to use the "asset" sintax.
I had this before: <link href="css/font-awesome.min.css" rel="stylesheet">
And now I change it to: <link href="{{ asset('css/font-awesome.min.css') }}" rel="stylesheet">
href="{{ asset('css/normalize.css') }}"

It worked!

Thanks!!! You are definitely amazing :D
Cheers!!

Woooh! Good find! Really happy it's working :)

Hey gstanto

> Why (and what) is the length requirement about? Is this new? My DB? Where do I find these specs?

That's a size limit constraint for "VARCHAR" field types in your DB (I'm assuming that you are using MySQL", by default those fields cannot be larger than 255 characters, but look's like, for some reason, your DB is using a smaller limit, as you already discovered. Why? Well, the Database needs to know how much memory a field requires, so it can assign it.

> When you create bad migrations like this, what is the recommended way to handle them?

You should definitely fix the SQL part that is wrong in the migration before adding it to the project's repository

Cheers!

makes perfect sense. thank you.

Hey Yang!

Yes, you definitely understand things correctly :). But, doctrine:fixtures:load is pretty smart: it attempts to order the DELETE queries to avoid constraint violations (e.g it would delete the Genus table before trying to delete the SubFamily table). This doesn't always work (sometimes you have circular references), but it does most of the time. But you're also right that if you set the "on delete" behavior, then that would make deleting easier. For example:

// in Genus.php
/**
 * @ORM\ManyToOne(targetEntity="AppBundle\Entity\SubFamily")
 * @ORM\JoinColumn(nullable=false, onDelete="CASCADE")
 */
private $subFamily;

With this setup, if a SubFamily were deleted, then all related Genus would also be deleted. As you know, this is done by setting the foreign key relationship in the database (i.e. the delete is done by the database itself). I usually don't set onDelete behavior until/unless I need it... because bad things can happen :).

Cheers!

Hey Lampje!

Bah, that is strange! When you use <email()> (good idea btw), what exact error do you get? Does it say "Duplicate entry 'weaverryan+1@gmail.com'"? Or does it say "Duplicate entry" but with a different email address? I'm sure this is something small, I would check a few things:

A) Make sure you don't have any other AppBundle\Entity\User entries in your fixtures file somewhere
B) Make sure don't have another email key under your users in the fixtures file
C) Double-check that your setEmail() method in User doesn't have anything funny

I've never had a problem with the randomization with Alice... which is why I'm looking for a simple answer :).

Cheers!

Yes, i get `'SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'weaverryan+1@gmail.com' for key

'UNIQ_8D93D649E7927C75''` 3 times.

I'm a bit further in the chapter and this still persists.. I've copied the .yml from the 'finished' dir, just to be sure that this doesn't have to do with tab's or something silly like that.

I've checked A, no other entries than:

AppBundle\Entity\Genus:
AppBundle\Entity\GenusNote:
AppBundle\Entity\SubFamily:
AppBundle\Entity\User:

No luck on B neither:

AppBundle\Entity\User:
    user_{1..10}:
        email: weaverryan+<current()>@gmail.com

C:

/**
 * @param string $email
 */
public function setEmail( $email ) {
   $this->email = $email;
}

Don't know if it matters, i'm using: 10.1.9-MariaDB as database.

Lampje Hmm, yea, I agree - it all looks good to me. If you use <email()> instead, do you get the same error? I mean, duplicate constraint "weaverryan+1@gmail.com"? Or is a duplicate constraint error with a different email (I'm trying to see if weaverryan+1@gmail.com is sneaking into the code in some other way). Or, what happens if you change weaverryan+ to something else in the fixtures file? Basically, if you play around a bit, do you see any other strange behavior?

It was a good idea to copy the code from the finished dir: those files are created programmatically from the real code that worked for the screencast, so it's definitely correct/good files to work from.

Let me know if you find out anything else - this is very strange!

Hey Ben,

Yes, really, changing the table name is the easiest solution. Thanks for sharing this with others!

Cheers!

Hey @claire,

You did it right to drop this table, but you didn't have to create it. Migration will create this table for you. This's exactly what migration trying to do based on the error message you got: "Base table or view already exists: 1050 Table 'genus' already exists". So the right solution is: Drop `genus` table and don't create it, just run a migration. If you will still get similar errors, try to drop database at all and run all migrations from scratch. And don't forget to load fixtures after it.

Cheers!

Hello Victor
I have the same case.
here i don't understand why Migration have to create genus table that already exists and the last migration file generated via doctrine:migrations:diff don't include any database action related to this table. I mean if i was in production i risque to loose my data to recreate this table?

Hi Zied,

First of all, *you* should always double check the queries inside any new migration, you can't just rely on Doctrine here. So if you see something that could break your production, i.e. potential data loss - then you need to correct the migration queries.

At second - you should understand well how migrations works and how to use it. If you decide to manage your DB with migrations - then you better need to forget about "bin/console doctrine:schema:update --force", because if you tweak your DB schema with this command - I bet your migrations failed on the next migrate.

Now let's consider the example: you create a new entity. It's a new entity, so it's a new table, which you have not had on prod yet, i.e. in your DB on prod one missing table for now. When you run "bin/console doctrine:migration:diff" - it will create a migration with query which create this table. Then you will need to run this migration on production server which creates this new table for you. So in this case no any data loss, everything is fine.

P.S. you probably won't lose your data on prod when migration recreate a table - this migration just will fail with error "Table already exist".

I hope I understand you right and it'll clarify something for you. Let me know if it makes sense for you.

Cheers!

Thank for your explanation.
1- What i doesn't understand is the following:
When i create a new entity and then i run doctrine:migrations:diff, it will generate a migration to create only the table corresponding to this entity. So why when i run doctrine:migrations:migrate it attempt to execute the older migrations not only the latest.
2- I figure out the situation by running doctrine:migrations:execute 20161124132920 (the last migration) is that correct?

Hey Zied!

Ah, here is the secret! In your database, the migrations library creates and manages a table called migration_versions. Whenever you execute a migration, it adds a new row in this table to record that the migration has finished. In fact, each time that you run doctrine:migrations:migrate, it looks at each file in your app/DoctrineMigrations directory, and checks the migration_versions table for each file to see if it has already been executed. If it has, it does not execute it. If it has not, then it executes it and records a new row in the table.

In our project (and this is the way I recommend doing it), we have created a migration for every database change (i.e. a migration to create every table). My guess is that you may have somehow created the genus table via some method other than running your migrations (e.g. by running doctrine:schema:update --force or doctrine:schema:create). Basically, you should never do this :), because it means that you have a genus table, but your migration_versions table is still empty. So when you try to execute your migrations, it runs all of the migrations, including those that try to build the genus table.

This whole system that uses the migration_versions table is designed so that things are very predictable when you deploy to production: when you run doctrine:migrations:migrate, Doctrine will look at the migration_versions table in your production database to determine exactly which migration files have already been executed and which have not been executed yet.

If you find yourself in a spot where your system is "messed up" and you've accidentally created some tables in a method other than by running your migrations, then I recommend (locally on your development machine) to restart from scratch:

bin/console doctrine:database:drop --force
bin/console doctrine:database:create
bin/console doctrine:migrations:migrate

This will drop the database, which is important because it will drop your migration_versions table. Then, it will run all of your existing migrations. NOW, you can create a new entity and run doctrine:migrations:diff. It will correctly generate, and when you run doctrine:migrations:migrate, Doctrine will know that you only have one new migration to execute.

Let me know if this helps! Cheers!

Hi Ryan, very clear now , it works for me.
I knew migrations from rails and when I got stack I thought that it is not the same idea, but your answer clarified everything.
Thanks.

Hey Victor,

aaa I see thank you for explaining that. I dropped the table and I ran migration but now getting this error:

[Doctrine\DBAL\Exception\ConnectionException]

An exception occured in driver: SQLSTATE[HY000] [1049] Unknown database 'claire_test'

I used ./bin/console doctrine:migrations:migrate

Is that the command to use to run all migrations ?

Thank you!

Ah, usually database creation is up to you. Migrations could create tables as you can see in the code of migrations for this course, but you have to create a DB manually, i.e. I mean you could create it easily by running the command:

$ bin/console doctrine:database:create

And when your DB exists - then start running migrations!

Cheers!

Hey Ernest H.!

Wow, that IS weird... we definitely know the fixtures are working... but strange that only the User table is not being loaded! Let's do some detective work: find the setEmail method in User and add this code:

public function setEmail($email)
{
    throw new \Exception('setEmail called with '.$email);

    $this->email = $email;
}

When you load your fixtures, do you now see this error? And does it show the correct email address (i.e. weaverryan+1@gmail.com)? I want to make sure that (1) the User fixtures are being loaded and (2) that there is not some other fixtures code for the User class somewhere else in the fixtures file that might be overriding this code.

Let me know what you find out! I've definitely never seen this problem before - so I bet it's something minor!

Cheers!

That error does not show.

I did confirm that if I manually load data into the users table (i.e., add a few email addresses), those entries do get wiped. That may be irrelevant depending on how the db gets purged. I don't see anything else in the User class that would affect this. I tried to paste the src/AppBundle/Entity/User.php file here but the comments in the code mess up the post here.

OK, I found the problem. Your hints helped figure it out. I somehow had a src/AppBundle/ORM/fixtures.yml file, but that is the wrong directory. I corrected it to src/AppBundle/DataFixtures/ORM/fixtures.yml and all is working now!!

Thanks very much.

Woohoo! Nice job finding the problem! The toughest bugs are when it's some small, tiny detail like this :D. Now, keep going!!

Hey somecallmetim ,

Good detective work! How do you encode your password and where? I suppose you do it in the event listener where encode plain password and store the encoded value in User::$password (as we do in our screencasts). Then in this event listener you have to add one more extra check: if user's plain password is null - then skip encoding it, because user doesn't set a new password.

Cheers!

Awesome! Worked like a charm. My sincerest thanks :)