[Pulp-dev] proposing changes to pulp 3 upload API

[Brian Bouterse]

@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 <jortel at redhat.com> 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
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20170630/df70a49b/attachment.htm>