Vichuploaderbundle: add the generated id to the filename

[matteosister]

By now it's not possible to give the Document (or Entity) a filename with the generated id. This is because the events is prePersist.

Are there any problems by changing prePersist to postPersist? (preUpdate is fine)
I could send you a PR. Maybe we should also add a parameter to let the user decide which lifecycle callback to use, and default to prePersist, so it won't break compatibility.

Let me know....

[dustin10]

The problem with postPersist is that the object would have to be saved to the db twice. Once to save the data then again after the file name is generated and set on the object.

[matteosister]

http://symfony.com/doc/2.0/cookbook/doctrine/file_uploads.html#using-the-id-as-the-filename

And what about this tecnique? I guess that the problem is that the filename isn't persisted to the db....but only the extension.

[stfalcon]

@dustin10 I think bundle should be have generator for unique filename.

example
https://github.com/stfalcon-studio/wallpaper/blob/master/src/Application/Bundle/DefaultBundle/Naming/WallpaperNaming.php

[dustin10]

Something like this is easily implemented by the developer. It would take quite a bit of work to actually do this. Your example assumes that getFile will always be the method that gets the file object. This is not the case.

[stfalcon]

I know. It's only example our implementation.
But I don't want write simple Namer on each project. Or copy-paste code from old projects :)

May be better to have a standard implementation? One or more

[DeluxZ]

How would you do this ? I need to name the file like generatedId.extension. Can't figure it out how to do this.

[ddeboer]

I wanted to do the same: name uploaded files based upon the database record's generated ID. Have a look at my PR #26, in which I try to solve the problem.

[ioleo]

@dustin10 i also think there should be some standard generated PK namer. I think it should work like..

For upload my-image.png do following:

• save original filename my-image to fileNameProperty
• save original extension .png to fileExtensionProperty (should be mapped, like fileNameProperty right now)
• get entitys PrimaryKey field (since it's not always ID)
• save file as primaryKey.png (nameing schema: primaryKeyValue + originalExtension), example 10.png for ID value 10

Also, for following configuration:

uri_prefix:           /
upload_destination:   media/product/files

We should make it possible to let user download the file with it's original filename:

• for /media/product/files/10.png where 10 is ID, return 10.png
• but for /media/product/files/10/download return my-image.png

[dustin10]

What happens when you have more than one uploadable field on the same entity? Can't use a pk namer in this case.

[ioleo]

@dustin10 Actually in my case i have a:

• Product entity with $files collection of File entities
• each File entity has only one uploadable field

(so PK here is ID of File entity)

So such a simple namer would suffice for me.

For more complicated cases (One entity -> many uploadable fields) the namer should follow schema: PK/property.ext where PK is used as a directory name.

For example:

Product:
* id (integer)  -> 10
* image (png file)  -> mp3player.png
* manual (pdf file)  -> mp3manual.pdf
* imageName  -> here we save name "mp3player"
* imageExt   -> here we save extension ".png"
* manualName   -> here we save name "mp3manual"
* manualExt   -> here we save extension ".pdf"

The schema should be:

• /path_specified_in_config/10/image.png
• /path_specified_in_config/10/manual.pdf

[ioleo]

Getting the name and extension useing pathinfo php function

[ioleo]

Also, in the last example, the paths to download would change to

We should make it possible to let user download the file with it's original filename:

• for /media/product/files/10/image.png
• but for /media/product/files/10/image/download return mp3player.png (orignal name)

And for manual:

• for /media/product/files/10/manual.pdf
• but for /media/product/files/10/manual/download return mp3manual.pdf (orignal name)

[kbond]

What about a "PostPersist" namer interface? If the namer implements this, during prePersist, the fileNameProperty is set to a random hash. During postPersist, the fileNameProperty is generated and the file is moved.

[K-Phoen]

Consider this issue as a "wont-fix" for now.

[grekpg]

Any plans to fix this issue?

[K-Phoen]

Not for the 1.0.x release, no. Maybe after.

[selim-b]

What about PostPersist ?

[K-Phoen]

PostPersist would require the entity to be persisted twice (once to generate an auto-incremented ID and a second time to generate the filename). That's simply not an option.

If you really want to use the ID of your entity, generating one in PHP is your best shot (see this comment)

[spackmat]

@K-Phoen Why is persisting the entity twice not an option? This would be just a really small performance-impact and only in the case of creation of an entity. So what's the problem with this?

Could be @kbond s suggestion with a "PostPersist" namer interface a solution making everybody happy? So that one can invest the costs of a second database write at will?

[garak]

Simple solution: DO NOT USE an auto-increment for your id. Use something that is predictable and you're done. Examples: UUID or ShortId.

[spackmat]

@garak that doesn't answer any of my questions. I wouldn't have asked if this was an option for me or the other folks asking for ID-based-directories over and over again.

[garak]

I'm sorry but we can't add complexity just to fit in poor implementations

[spackmat]

OK, then I have to reimplement my upload without this bundle.

So could you at least be so kind and document this strong opinionated decision prominently? So that other folks with poor implementations don't step into this funny little boobie trap again. This could stop all those new issues opened here regarding ID based directories.

[garak]

Feel free to propose a PR for documentation

[spackmat]

No thanks, already wasted too much time with this bundle.

[Seb33300]

I'm sorry but we can't add complexity just to fit in poor implementations

Auto increment is still the default behavior when creating entities with Symfony, and this is what most of the projects are using.
UUID is just an alternative, and not necessary a better implementation.

I can understand that adding support for auto increment can be quite complex and not really efficient in terms of performance.
But IMO, this is worth it to support it. Because this is a very common use case and this can simplify the life for many of us.

[garak]

@Seb33300 I understand that using autoincrement IDs can be an acceptable tradeoff.
But using such IDs for other than keys and relations is not.

[stefankleff]

I want to share my solution for some id generation strategies (autoincrement is NOT working).
We're using UUIDs for the PK and this works fine:

https://gist.github.com/stefankleff/a4e0a2f546f5526cec3678213b829d06