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?

  • 2
    You'd do a one to many relationship between tables in your database. – GrandmasterB Jan 11 '15 at 2:22
  • @Grandmasterb, but I can't get the id of the parent table when I save the child? – the_ Jan 11 '15 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 '15 at 3:30
  • @GrandmasterB, You're right. I need to rephrase my question. – the_ Jan 11 '15 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 '15 at 10:57
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 | |
  • 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 '15 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 '15 at 16:35
  • @TMN, how could I make sure the surrogate key is unique though? – the_ Jan 29 '15 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. – Vlad Spreys Jan 30 '15 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 '15 at 16:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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