add the generated id to the filename about vichuploaderbundle HOT 28 CLOSED

@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

from vichuploaderbundle.

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.

from vichuploaderbundle.

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

from vichuploaderbundle.

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.

from vichuploaderbundle.

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

from vichuploaderbundle.

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.

from vichuploaderbundle.

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.

from vichuploaderbundle.

@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

from vichuploaderbundle.

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.

from vichuploaderbundle.

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

from vichuploaderbundle.

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

from vichuploaderbundle.

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.

from vichuploaderbundle.

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

from vichuploaderbundle.

@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

from vichuploaderbundle.

Getting the name and extension useing pathinfo php function

from vichuploaderbundle.

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)

from vichuploaderbundle.

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

from vichuploaderbundle.

Any plans to fix this issue?

from vichuploaderbundle.

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

from vichuploaderbundle.

What about PostPersist ?

from vichuploaderbundle.

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)

from vichuploaderbundle.

@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?

from vichuploaderbundle.

@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.

from vichuploaderbundle.

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

from vichuploaderbundle.

Feel free to propose a PR for documentation

from vichuploaderbundle.

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

from vichuploaderbundle.

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.

from vichuploaderbundle.

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

from vichuploaderbundle.