[22:08] <cjohnston> josepht: mhall119, mhall119: josepht
[22:08] <josepht> mhall119: greetings
[22:08] <cjohnston> josepht: 17.05.53 <mhall119> how many ImageResults will you have per machine_id?
[22:08] <cjohnston> 17.06.16 <mhall119> also, how many image arches would you have per machine_id?
[22:09] <cjohnston> 'huge' is a valid answer, correct?
[22:09] <josepht> yes
[22:09] <josepht> likely a couple of image arches per machine
[22:09] <cjohnston> 17.08.25 <mhall119> so really you want images per machine, not imageresult
[22:10] <cjohnston> he just stepped out to dinner
[22:10] <josepht> probably dozens of imageresults per machine per arch per day
[22:10] <mhall119> have you guys thought about just making an M2M between Image and Machine?
[22:11] <mhall119> because using ImageResult to link the two is going to have this kind of trouble, and won't scale very well
[22:14] <josepht> mhall119: where does the data for each run reside then?
[22:16] <mhall119> josepht: keep ImageResult, but make another table directly linking Image and Machine that has only one record per machine+image combination
[22:16] <mhall119> then, whenever you make a new ImageResult, check to see if there's an existing record in the new table, and add one if there is not
[22:17] <mhall119> you can do that by overriding ImageResult.save()
[22:18] <josepht> where's the M2M relation then between ImageResult and ImageMachine?
[22:18] <mhall119> they both have machine_id and image_id
[22:18] <mhall119> you can use those
[22:19] <mhall119> ok, really going to dinner now
[22:20] <josepht> mhall119: k, thanks for the input
[22:20] <mhall119> np