I added 2 more stories based on the discussion we've had so far. Please provide feedback here or on the tickets.
https://pulp.plan.io/issues/2872 https://pulp.plan.io/issues/2873 On Fri, Jun 30, 2017 at 2:23 PM, Brian Bouterse <[email protected]> wrote: > @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 > >
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
