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

Datamapper keep trying to validate my image fields as a string #87

Closed
clodeindustrie opened this issue Jul 14, 2010 · 12 comments
Closed

Comments

@clodeindustrie
Copy link

Hi,
using datamapper 10.0.

I have a class as follow:
class Site
include DataMapper::Resource
property :id, Serial
property :titre, String
property :created_at, DateTime
property :route, String
property :image, String
property :caption, Text
property :tips, Text
property :annee, Integer

  validates_present :titre
  validates_present :route
  # validates_present :image 
  validates_present :caption
  validates_present :annee

  mount_uploader :image, ImageUploader
end

When I try to stick my file object from a form upload into the image fields, datamapper expect a a String and returns an error, my site object failing validation.

Any clue ?

Thanks

@clodeindustrie
Copy link
Author

Nobody? really? I'm just trying to use the most basic function of Carrierwave with datamapper, nothing fancy. No one is able to help me ?

@solon
Copy link

solon commented Sep 8, 2010

I'm also having trouble getting Carrierwave working with Datamapper.

A barebones Sinatra example that I'm testing with:
http://pastie.org/1145826

When I try to upload a file, I get this console output:
http://pastie.org/1145837

Here are the gems I have installed:
http://pastie.org/1145832

FWIW I have no trouble using Carrierwave without Datamapper. As a workaround I am currently storing the file path as a string in the model. However once I add mount_uploader into my model it stops working. Quite frustrating... any suggestions would be greatly appreciated.

@mbj
Copy link

mbj commented Sep 8, 2010

I ran into the same problem. If you embed your property definition into an without_auto_validations block the problem is gone.

Also carrierwave does not mark my models dirty once I assign a new file.

@solon
Copy link

solon commented Sep 8, 2010

Thanks Markus! That seemed to do the trick.

Cheers,
Brian

@jnicklas
Copy link
Member

mbj: the dirty tracking issue should be solved on master. A real pain in the ass.

Not sure what to do about the auto validations thing, maybe just a doc patch?

@wprater
Copy link
Contributor

wprater commented Oct 8, 2010

Im also have a lot of trouble with DataMapper. I've found that you can use :auto_validation => false on your property to get past the validation issue. However, we're still not able to get the field marked as dirty on master.

@marckohlbrugge
Copy link

Any of you got CarrierWave working w/ Datamapper at all?

@solon
Copy link

solon commented Jan 27, 2011

As far as I know, it is still only usable with a workaround, as described by mbj and wprater above. The problem with DataMapper not marking the field as dirty means that in practice, updates to a model that only affect the CarrierWave field don't get applied unless another field is also modified before saving.

A fix was proposed for this bug over here: https://github.com/jnicklas/carrierwave/issues#issue/142

@marckohlbrugge
Copy link

I must have a different issue than. It saves the uploads to disk, but doesn't attach them to the model (even though other fields are being saved fine).

@mbj
Copy link

mbj commented Jan 28, 2011

I got datamapper w carrierwave working successfully in a medium sized ab. Im using carrierwave to attach files to my image models. These models are immutable you can create and destory them, but not do any updates on them. So the dirty issue does not hit me.

I begun to dig the carrierwave and datamapper sources, maybe I'll find some workarounds. I'll add pull requests on success.

@trevorturk
Copy link
Contributor

I'm going to close this issue and add the note about validations from wprater to the wiki. If you are afraid that's not visible enough, please provide a documentation patch in a pull request.

@trevorturk
Copy link
Contributor

I'm not 100% sure what to put there :(

I put something, but can someone who knows about this please review and make any necessary edits? Thank you!

Again, this may be worth a documentation patch. I'd welcome a pull request!

This issue was closed.
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

7 participants