4

I have an application where users will be able to upload multiple images for one Product (via something like Ryan Bates nested fields, so you'd click "Add Image", and a file upload would appear on the same page). I'm planning on using jQuery File Upload, and Amazon S3, and nested fields.

The thing I'm confused about, is how people usually associate many images with a single model.

For example, if for every Product, there can be many Images, how do I store the images to be associated with the Product?

I was thinking of having jQuery File Upload return the s3 url for each image. So if 10 images were uploaded, then 10 hidden fields were created for each image-url, which I then JSON serialize and store in the Product model?

But this doesn't seem like a pretty solution? What's a better method?

Improve this question
5
  • 2
    You'd do a one to many relationship between tables in your database.
    – GrandmasterB
    Jan 11, 2015 at 2:22
  • @Grandmasterb, but I can't get the id of the parent table when I save the child?
    – the_
    Jan 11, 2015 at 2:44
  • 1
    I have no idea what that is supposed to mean. I think you need to edit your question to better explain the problem you are encountering.
    – GrandmasterB
    Jan 11, 2015 at 3:30
  • @GrandmasterB, You're right. I need to rephrase my question.
    – the_
    Jan 11, 2015 at 5:34
  • @the_ Why can't you get the id of the parent when saving the child? Surely you can by first saving the Product and then saving the images afterwards?
    – Alternatex
    Jan 20, 2015 at 10:57

2 Answers 2

Reset to default
2

Your main question is,

The thing I'm confused about, is how people usually associate many images with a single model.

So I'll focus on that:

In practice, Rails devs do this by using one of the gems for uploading and attaching images. E.g., Paperclip is maintained by Thoughtbot, is very well tested and supports S3.

But if you're more interested in experimenting and writing your own, you should take a look at Paperclip's source code to see what the current state-of-the-art is.

Improve this answer
0

It sounds to me like you 2 tables: a Product table, and an Image table. The Image table will have a foreign key back to the Product table and will store the image URL.

This way, a single Product can have a bunch of Images.

     Product                           Image
    +-----------------+              +-----------+
    |ProductID        |<------------+| ImageID   |
    |ProductName      |              | ProductID |
    |... and so on ...|              | ImageURL  |
    |                 |              |           |
    +-----------------+              +-----------+

(ImageID doesn't really matter much for this diagram)

Improve this answer
7
  • but because I'm using nested fields, I don't yet have the Product Id when I save the image id via a jquery File Upload ajax request?
    – the_
    Jan 29, 2015 at 5:16
  • Three things you can do: (1) save the parent first to get the ID, (2) have an ID generator you can call to set the ID before you save it, or (3) generate a separate (non-primary) ID to act as a surrogate key and store that in a separate field in Product (say ProductImageID).
    – TMN
    Jan 29, 2015 at 16:35
  • @TMN, how could I make sure the surrogate key is unique though?
    – the_
    Jan 29, 2015 at 20:33
  • @the_ You can consider creating a product record as soon as your users enters the page. This way you have an ID nice and early. You can have a process which cleans out the DB from not finished products.
    – Allan Spreys
    Jan 30, 2015 at 9:12
  • 2
    @the_: UUIDs would be better, since random number generators can (by design) produce the same number more than once. Since you're using Postgres, I'd recommend just using a sequence.
    – TMN
    Feb 2, 2015 at 16:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.