@jortel I think what you've written is what we should do. I think we can get a race-condition free implementation with this many-to-many table with the database transaction including the the filesystem operations. +1 to adding the relative path to the join table also.
I'm also not sure about including <name> in File.path <--- FileField: MEDIA_ROOT/files/digest[0:2]/digest[2:]/<name> If there were collisions, having <name> would allow you to store two Files with different contents but the same hash. It's highly, highly improbable even if Pulp is storing billions of files, but it could happen. A content addressable store (not including <name>) would never be able to handle this case. Even still, I think we should disinclude the name from the path to the Artifact and just have it be the digest. Having a fully addressable File storage will be awesome, and a bit more complex code in core is worth it (I think). FWIW, I also don't think it will be that hard to get right. As a side point, I think when a file with the same sha256 is uploaded a second time it should be rejected rather than silently accepting it. On Fri, Jun 30, 2017 at 12:00 PM, Jeff Ortel <[email protected]> wrote: > Ah, I missed adding the relative path to the join table. This is a fine > idea as well. > > On 06/30/2017 10:15 AM, Michael Hrivnak wrote: > > > > Jeff, earlier in the thread we talked about using the through table to > hold the path. I think that's the right > > place, because the path would be a property of the relationship between > an artifact and a content unit. It > > also occurred to me that the file name could be different for different > content, so maybe the path would need > > to include the filename. That seems a bit weird, but I think it has to > be the case if we use a many-to-many > > relationship. > > > _______________________________________________ > Pulp-dev mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/pulp-dev > >
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
