Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Carrierwave Direct changes old uploads path #118

Closed
shlomizadok opened this issue Dec 8, 2013 · 4 comments
Closed

Carrierwave Direct changes old uploads path #118

shlomizadok opened this issue Dec 8, 2013 · 4 comments

Comments

@shlomizadok
Copy link

Hi,
Until recently we have used CarrierWave gem to upload our files.
We have now changed to carrierwave_direct and it works excellently (thanks!), besides one issue:

When we update model's attribute, without changing the file, when saving it adds the store_dir parameter anyhow, so if in my Book model - one book looked like:
{ name => "Hello Carrierwave Direct", key => "books/hello.epub" }
After editing (the name only) it would change to
{ name => "Hello edited name", key => "books/books/hello.epub" }

It adds automatically "books/" (yet it will not add the "books" if I have replaced the file via carrierwave_direct

Any clue?

@nddeluca
Copy link
Collaborator

nddeluca commented Dec 9, 2013

I think this may be related to #101, which is a result of incompatibilities between carrierwave and carrierwave_direct unfortunately. Can you try https://github.com/nddeluca/carrierwave_direct on master and see if that fixed your issue? I have a fix for #101 there and am working towards getting it ready to be merged into carrierwave_direct's master.

@shlomizadok
Copy link
Author

I'm afraid it is not related. I have set my gem to run vs. nddeluca/carrierwave_direct and I get the same result. :\

@shlomizadok
Copy link
Author

@nddeluca, I think I found a solution on your fork, I have created a pull request (nddeluca#1) -- return old key if the new key equals the old key.
It works for me. Let me know if it doesn't break anything on your side and the logic is good.
(btw, nice refactoring you did there...)

@p8
Copy link
Collaborator

p8 commented Jul 2, 2018

This should be fixed on master

@p8 p8 closed this as completed Jul 2, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants