I have come across this issue in my current project, but I have not had time to dive into it further. I have just implemented a little hack in my entities right now similar to the following:

public function setFile($file)
{
    $this->file = $file;

    if ($file instanceof UploadedFile) {
        $this->setUpdatedAt(new \DateTime());
    }
}

Hopefully I will have time to look into this soon.

Thanks :)

Uhh Ohh dirty! :)
But thanks ;)

I believe this is an issue with the framework itself, and not this bundle in particular. I've run up against it as well, independently of this uploader, and I'm looking into it too.

+1 ;)

cool workaround, hoping it will be fixed soon

thanks guys! You have saved my day!

I have this issue too maybe this could be fixed in this bundle.

Same issue here. I guess this is because Doctrine doesn't detect any changes when only a file is uploaded as the "file" member variable is not mapped as a database column.

I'm just guessing, though.

This is an issue with doctrine, which wont persist the entity if it doesn't see any changes. I have an issue in the main Symfony project here: symfony/symfony#5150 (comment)

As I've explained to @aderuwe, this is kinda wrong.
This should not be pushed down to event listeners/subscribers attached to Doctrine ORM.
Since you're dealing with transitient fields here (not related with persistence) you are basically mixing persistence logic with the Bundle's logic. Don't do that.
Instead, I'd suggest to fix with something like

public function updateFile(UploadedFile $newFile, YourOwnServiceStuffYouRequire $service)

and perform all the persistence operations related to the file itself there.
The fix by @dustin10 is valid just to avoid breaking BC, but please stop doing this, and instead set a persistent field's value before flushing (Not in preFlush or other nasty hacks: really, just do it BEFORE interacting with Doctrine's UoW lifecycle!)

Hi @Ocramius, I would like to discuss this with you, will you be available for a quick chat on this topic ?

@ftassi ping me on IRC tomorrow eventually ( #doctrine )

Same problem, still waiting...

Thanks.

@dustin10, maybe you have a normal solution? much time has passed.

Doctrine uses identical operator (===) to compare changes between old and new values. The operator used on the same object with different data always return true. The best way is to clone the object.

@stof, maybe you can help resolve this problem?

Guys, I researched this issue and think it's unsolvable problem for current architecture :(

This hack should be added to the documentation

maybe preFlush event can helps?

@Koc I tried. I couldn't get entity in preFlush event

The only way to go is, to use the vich_uploader.storage service manually.

$form = $this->createForm(new AcmeType(), $entity);
$form->bind($request);

if ($form->isValid()) {
    // Upload the new file
    $storage = $this->container->get('vich_uploader.storage');
    $storage->upload($entity);

   // Save the new filename
   $om->persist($entity);
   $om->flush();

    return new RidirectRespone('/');
}

@Ocramius Right?

@Baachi maybe. but still doesn't work in SonataAdminBundle (from the box) :(

@stfalcon Hm i doesn't work with SonataAdminBundle.
But i use custom events to upload my images/files, so SonataAdminBundle should call his own events, too.

Maybe you can bake the hack into the sonata code?

@MisterGlass I thought about it. need to try

Right now the bundle is coupled to doctrine's lifecycle callback, which means that with no changes to the entity, no callback are called and no upload is triggered.

With this coupling there are two options to solve this problem:

1. Add an updated field as suggested here
2. Manually upload the file as suggested here

The second one is my favorite and in the future I would like to loose coupling with persistence layer, but I've not implemented this yet and I'm afraid that I'll not do it soonish.

I think that if there is no generic fix for the moment then the workaround(s) should be added to the documentation.

👍
We could add a "known issues" (or known limitations) section where we can explain this and why we can't use the id of the object for file name (ref: #14)

Any chance to work on a PR ?