Author ManyToOne Relation to User

Hey @Matt

Thanks for the feedback, we don't love to say "start over from our code" but sometimes it's unavoidable

Cheers!

now, the process doesn't finish, it just hangs the CPU ....

Hey Ad F.!

Hmm. I might have an idea. Did you download the fresh "start" code for this tutorial? Or are you using the code from the previous tutorials? I'm asking because, before this tutorial, I did some refactoring on our fixture system to make it more robust. Based on your error, it *looks* like you may be using the old code - but let me know.

Cheers!

i’m using the code from previous tutorials.
also. you are using comment entity on ArticlesFixtures but you don’t mention it.

Hey @cybernet2u!

Ah! That’s it then! At the very beginning of the tutorial, I mention that some of the fixture code has been updated between the tutorials and that you should download thecfresh code to get it. The way I built the createMany() function in the fixtures was a bit limited. I fixed that before this tutorial.

I hope that help!

Cheers!

i got the fresh code, now i'm trying to work with relations

$category->setParentCategory($this->getRandomReferences(MainCategory::class, $this->faker->numberBetween(0, 9)));

Argument 1 passed to App\Entity\Category::setParentCategory() must be an instance of App\Entity\MainCategory or null, array given.

don't know how to fix it ...

no fixture seems to persist ...

Hi Ad F.

->setParentCategory() expects one object and you are using $this->getRandomReferences() which returns array of objects, you should use $this->getRandomReference to get only one object.

Hope this will fix your error

Cheers!

now, the process doesn't finish, it just hangs

Hey Remus M.!

Interesting! I wonder if something is being called recursively... or if something is stuck in a loop! Do you have XDebug installed? It would at least throw an error in case there is something being called recursively. Or, you can post your code and we can have a look. It definitely looks strange!

Cheers!

can you tell me your bitbucket username ? :D

weaverryan :)

can you please update the tutorial, what you have in course script is different from the code on the website, it's very confusing :(

$this->createMany(10, 'main_articles', function($count) use ($manager)

is different than the one in BaseFixture

Hey Remus M.!

Hmm. What do you mean by the code in the "course script"? Do you mean the code blocks on the page? Or do you mean the code download? Or something different? Those are actually all generated from the same exact place. But I do think there is something that, at the very least, must be confusing. Let me know what you're seeing and we'll see what we can do! :)

Cheers!

if i use the code from website code blocks

" $this->createMany(10, 'main_articles', function($count) use ($manager) "
it's not "compatible" with functions from BaseFixture

" protected function createMany(string $className, int $count, callable $factory) "

Are you using the code from the previous tutorial? Because Ryan made some improvements to the fixtures base class on this tutorial

i'm using the code from downloaded zip :)

Really? That's weird, I just downloaded it and double checked the method's signature. It looks fine:

// src/DataFixtures/BaseFixture.php
...
protected function createMany(int $count, string $groupName, callable $factory)

check this tutorial and see why this all got sooooo confusing ...

https://symfonycasts.com/sc...

Ohh right! that's because of the improvements that Ryan made to that class for this Course. The base class from the previous course is not compatible for this course.
I'm sorry for all this confussion

figured as much, however the problem is still there
how do i accomplish what i need, setAuthor, from a generated Fixture ?

Hey Ad F.!

I've just pushed a pull request to your BitBucket repository that updates all of your fixture classes to the latest version and fixes an infinite recursion issue that accidentally slipped into your code. Each change is on its own commit, so I hope it will help you forward!

Cheers!

Hey Oliver,

Look closer to your fixtures code, looks like Fixtures system cannot find any reference of "main_users". I suppose you need to look at your UserFixture class where we create those references with "main_users" name. Probably you mistyped it, e.g. call it "main_user"?

I hope this helps!

Cheers!

Victor, you are completely right. Thx

Hey Oliver,

Awesome, thanks for confirming the problem was in that! Easy fix then ;)

Cheers!

Hey sasa1007

I think the easiest thing you can do is to NOT serialize the File property of your User class

Cheers!

Thank you, but I did not serialize anything.

I saw on the stackoverflow that problem is:

"The problem is, when User Entity was implementing the UserInterface, the user provider(actually the Doctrine, behind the scene) tried to Serializing the User object to store it in the session but because of the file that I assigned it to this class, it fails it's career!"

I dont know how to control what will be Serialized what not.

This is my Entity:

class Team
{

...

/**
* @ORM\OneToMany(targetEntity="App\Entity\User", mappedBy="team")
*/
private $users;

public function __construct()
{

$this->users = new ArrayCollection();
}

public function getUsers(): Collection
{
return $this->users;
}

public function addUser(User $user): self
{
if (!$this->users->contains($user)) {
$this->users[] = $user;
$user->setTeam($this);
}

return $this;
}

public function removeUser(User $user): self
{
if ($this->users->contains($user)) {
$this->users->removeElement($user);
// set the owning side to null (unless already changed)
if ($user->getTeam() === $this) {
$user->setTeam(null);
}
}

return $this;
}
...
}

Hey sasa1007!

Ah, yes. I think I understand what's going on. At the end of the request, the User object that the user is logged in as is serialized to the session. By default, all properties are serialized. Normally... that's great! But you've found a case where it *doesn't* work great: we want this "picture" property (or whatever it's called) to *not* be serialized. There are 2 solutions:

1) (the solution I like less) Make your User class implement SerializableInterface and then take control of which fields are serialized and deserialized. Be sure to include the id, password, roles and whatever your getUsername() method returns (so, the username or email property). I hate doing this... because it's annoying and error prone.

2) After you handle the upload inside your "edit" controller, just set that property back to null - e.g. $user->setPicture(null). Then, when the User object is serialized to the session at the end of the request, it should work fine.

Let me know how it goes!

Cheers!

Actually, the first solution is more atractive to me, to take control over what I want to be serialized, but I dont know how, so I try second solution and working fine.

Thank You so much

Hey Christoph

That's odd. Could you double check that your database is in sync with your mapping files? You can run php bin/console d:s:validate
Other things to consider:

• Double check you are running on dev environment
• Clear the cache (just in case)
• If the problem persists, try recreating the database from scratch

cheers!

Hi Diego and thanks for your help

Yes, you are right: the database is not in sync.I ran doctrine:schema:validate
and it says:

Mapping

[OK] The mapping files are correct.

Database

[ERROR] The database schema is not in sync with the current mapping file

I am doing cache:clear very frequently.
I double-checked that im on dev.
I made a recreate of database:

<br />doctrine:schema:drop --force --full-database<br />Deleted all migrations-files in src/Migrations<br />make:migration (created 1 bigger migration file)<br />doctrine:migrations:migrate<br />

But i still got the same error on: doctrine:schema:validate . My database is still not in synch.

Maybe its my environment, im doing on Windows and XAMPP php 7.1 which comes with MariaDB instead of MySQL.
MariaDB and MySQL is nearly identical, but maybe in this case: only "nearly".... :-)

So, i will give up on this for now and will not dig in too deep. Maybe at a later moment...

greetings
Chris

Hey Chris!

Ah, indeed - the MariaDB part might hold the key! Check out this issue: https://github.com/doctrine/dbal/issues/2985 - and the possible fix - https://github.com/symfony/symfony-docs/pull/9547/files - that server_version is config that you'll find in your config/packages/doctrine.yaml file.

Let me know if it helps!

Cheers!

Hey Mike,

Nope, you're confused with those commands. If you need to drop DB schema, i.e. remove tables in the DB, use:
bin/console doctrine:schema:drop --force

But the command will drop only tables that are pointed from your entities, i.e. will use Class Metadata to detect the database table schema. If you want to drop ALL tables even if they do not have corresponding entity in your project, use:
bin/console doctrine:schema:drop --force --full-database

If you want to drop the DB, i.e. including all the tables inside of it, use:
bin/console doctrine:database:drop --force

So, if you want to drop DB - you may skip the doctrine:schema:drop command because the last one will remove the DB that means all its tables will be removed as well.

P.S. If you not sure about the command - use --help option to get more context about those commands, i.e.
bin/console doctrine:schema:drop --help

Cheers!

Hey Nethik

Yep, that's totally a Ryan's mistake :)
Thanks for highlighting it, we will fix it soon. Cheers!

Hey Dominik

I believe that part is never shown on the videos, it is just an upgrade Ryan made to the Fixtures base class, so now you can add references to your objects easier.

Cheers!