gzigzigzeo / carrierwave-meta Goto Github PK

Not sure if it was a change in the design or just an oversight.

The column names for the x,y,h,w need to be:
crop_source_x etc.

So in the example they would be:
image_crop_source_crop_x
image_crop_source_crop_y
image_crop_source_crop_h
image_crop_source_crop_w

The field name should be e.g. image_type or image_mime_type, referring to the image's MIME type, rather than image_content_type, since only MIME-like messages have content types.

"Content-Type" comes from the HTTP response (and multipart request header) header of that name. There are many headers prefixed with Content- though, including Content-Length and Content-Encoding, and their purpose is to describe the content of the HTTP response. As an example of their meaning: the Content in this response has a Type of application/html, a Length of 12943 in bytes, and an Encoding of gzip.

The following are standard headers in HTTP request messages, HTTP response messages, or multipart/form-data messages:

• Content-Disposition
• Content-Encoding
• Content-Language
• Content-Length
• Content-Location
• Content-MD5
• Content-Range
• Content-Transfer-Encoding
• Content-Type

They describe the Content part of the message, just like the field image_type should describe the image part of the model object.

It stores the data as YAML (which seems like overkill anyways), and when calling image_size it doesn't return the array but the string instead.

Sweepstake.first.invite_button.image_size
  Sweepstake Load (0.4ms)  SELECT `sweepstakes`.* FROM `sweepstakes` LIMIT 1
=> "---\n- 521\n- 388\n"

Attempt to use image_size_s

Sweepstake.first.invite_button.image_size_s
  Sweepstake Load (0.4ms)  SELECT `sweepstakes`.* FROM `sweepstakes` LIMIT 1
NoMethodError: undefined method `join' for "---\n- 521\n- 388\n":String
from /Users/robertross/.rbenv/versions/1.9.3-p194-perf/lib/ruby/gems/1.9.1/gems/carrierwave-meta-0.0.4/lib/carrierwave-meta/meta.rb:40:in `image_size_s'

recreate_versions! does not seem to update versions meta data.

RubyGems.org doesn't report a license for your gem. This is because it is not specified in the gemspec of your last release.

via e.g.

spec.license = 'MIT'
# or
spec.licenses = ['MIT', 'GPL-2']

Including a license in your gemspec is an easy way for rubygems.org and other tools to check how your gem is licensed. As you can image, scanning your repository for a LICENSE file or parsing the README, and then attempting to identify the license or licenses is much more difficult and more error prone. So, even for projects that already specify a license, including a license in your gemspec is a good practice. See, for example, how rubygems.org uses the gemspec to display the rails gem license.

There is even a License Finder gem to help companies/individuals ensure all gems they use meet their licensing needs. This tool depends on license information being available in the gemspec. This is an important enough issue that even Bundler now generates gems with a default 'MIT' license.

I hope you'll consider specifying a license in your gemspec. If not, please just close the issue with a nice message. In either case, I'll follow up. Thanks for your time!

Appendix:

If you need help choosing a license (sorry, I haven't checked your readme or looked for a license file), GitHub has created a license picker tool. Code without a license specified defaults to 'All rights reserved'-- denying others all rights to use of the code.
Here's a list of the license names I've found and their frequencies

p.s. In case you're wondering how I found you and why I made this issue, it's because I'm collecting stats on gems (I was originally looking for download data) and decided to collect license metadata,too, and make issues for gemspecs not specifying a license as a public service :). See the previous link or my blog post aobut this project for more information.

Hi,
Can carrierwave-meta support save the meta to single text column?
It will be much easier to maintain the db schema when we have to add new versions.
Thank you.

https://github.com/y8/paperclip-meta

The uploading of a file to AWS S3 works well, but the retrieving don't. CarrierWave-meta use the method set_content_type, from the MimeTypes module, which call the other method original_filename, from the File module, but that doesn't exist with Fog.
Why does the method set_content_type is called after each retrieving of a file ?

The way carrierwave works with fallback images is the following:

Let's say you have an uploader with an additional process of a thumbnail. If for some reason the thumbnail process fails it falls back to the original image. IE.

@product.image.thumbnail.url => #return the url of the original image if you don't have a thumbnail

This doesn't work for the meta. If you would do the following:

@product.image.thumbnail.width => 0

You would get 0 because the thumbnail never got processed, shouldn't it fallback to running the identify on the original image or maybe delegate the methods? I'd be happy to submit a pull request if I could be pointed in the right direction.

This clearly becomes a problem when you're testing your UI and you don't have access to your meta, because you turned processing off.

Hi,

Currently, if I create a record that utilizes carrierwave::meta on its carrierwave mounted column, the metadata is loaded as instance values. If I fetch the record again my_model= MyModel.find(1) though, I have to manually call my_model.image.store_meta to get the metadata to load. I'm wondering if this is by design? If so, I guess the best way to handle this case is to call the store_meta method on the uploader in an initialization callback.

Btw, love the gem.

This gem isn't compatible with Cloudinary.

Calling model.image only gets me a string when they're used together.

I'm guessing it's because you're not using RMagick or any local transformations when uploading to Cloudinary.