In T2310#43131, @ardumont wrote:

Thanks for the questions. I'm unsure about some questions and i replied as best
i could.

do we allow an OriginVisitUpdate(status='ongoing', snaphost=None)? what would
be the meaning of this?

Yes. It means "loading started, so no snapshot yet".
That sounds sensible ;)

In T2310#43129, @vlorentz wrote:

We currently don't have "created" (so no "start" either), but it would make sense to create it.

Regarding this model, a few questions come to my mind:

• do we allow an OriginVisitUpdate(status='ongoing', snaphost=None)? what would be the meaning of this? or do we enforce one just after the created step to model the start transition?

This could mean these things:

1. on a first update, to mean the visit was created (but we don't need it if we have a "created" state)

As I understand this, an origin visit, consisting in one OriginVisit object plus a list of OriginVisitUpdate represent the process of visiting an origin to load its content in the archive.

rebase + add comment on @overload usage

rebase + modify tox as well

rebased

closed by f6a398f99a5fa57e590fc4dfaf4fdc880eefba9d

rebased

Let's consider this done with the landing of D2819 which adds runtime type validation.

see D2940

LGTM

closed by ca0f6a1eb7e6079ee0b8a649ff40353409c86560

closed by 414a6552143a1e2406bb980ed905969f4b778ad7

closed by f51327138fa14c5b285ffad2b2844afbb48e8462

closed by 20baa1b0bb3359e3a91a249fa1bae4d78cf1ddf2

closed by df3207a6b753b254e945db492227b3bb9bbac7d6

closed by fa4a043887e960731da5373f92e3f951ba411bc5

closed by fcca905a95a262dc5596ff2afd71c657a1bcb522

In D2914#70906, @vlorentz wrote:

In D2914#70849, @douardda wrote:

In D2914#70601, @vlorentz wrote:

it also misses tests to check date_to_db is used in release_to_db and revision_to_db

ok (but plz give all the infos/comments at once!)

It was a comment on your new version on the diff.

rebase

rebase

rebase + update for new origin visit updates entity

rebas

rebase

rebased

In D2914#70849, @douardda wrote:

In D2914#70601, @vlorentz wrote:

it also misses tests to check date_to_db is used in release_to_db and revision_to_db

ok (but plz give all the infos/comments at once!)

In D2914#70601, @vlorentz wrote:

it also misses tests to check date_to_db is used in release_to_db and revision_to_db

add a test for ctime as string in Content.from_dict()

In D2918#70261, @vlorentz wrote:

DULWICH_TARGET_TYPES are already the right enum values.

Typo in the first commit message

with the actual revision merged in...

In D2916#70253, @vlorentz wrote:

This is going in the right direction, but I don't like the CassObject thing. I think you made it because you are conflating two uses of my "Frankenstein's model objects":

1. Reads, where you can use the row directly (it's a namedtuple, so attr access)
2. Writes, where a dict would do (item access)

add a test for date_to_db so the test coverage of this later stays the same

Rebase + comments from vlorentz

Rebase

Get rid of unnecessary calls to builds() as reported by vlorentz

In D2905#70213, @vlorentz wrote:

You should rewrite all the object-generating strategies:

def releases():
    return builds(
        Release.from_dict,
        releases_d())

becomes:

releases = releases_d().map(Release.from_dict)

build() is only useful if you want hypothesis to read the constructor's signature.