Page MenuHomeSoftware Heritage

Add a split_content argument to object_dicts() and objects() strategies
ClosedPublic

Authored by douardda on Apr 21 2020, 2:54 PM.

Details

Summary

Make it possible to generate Content and SkippedContent under different
object types (namely "content" and "skipped_content").

Default to False to keep backward compat.

Depends on D3037.

Diff Detail

Repository
rDMOD Data model
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

Build is green

Patch application report for D3040 (id=10801)

Could not rebase; Attempt merge onto bfba3bdda5...

Updating bfba3bd..1037e88
Fast-forward
 swh/model/hypothesis_strategies.py            | 79 +++++++++++++++++++--------
 swh/model/tests/test_hypothesis_strategies.py | 52 ++++++++++++++++--
 2 files changed, 105 insertions(+), 26 deletions(-)
Changes applied before test
commit 1037e88d97384c4c9b87d37d8b2d3dafc0e821d6
Author: David Douard <david.douard@sdfa3.org>
Date:   Tue Apr 21 14:49:14 2020 +0200

    Add a split_content argument to object_dicts() and objects() strategies
    
    Make it possible to generate Content and SkippedContent under different
    object types (namely "content" and "skipped_content").
    
    Default to False to keep backward compat.

commit ebd38077962687e0f962d1edab275f6d33b72312
Author: David Douard <david.douard@sdfa3.org>
Date:   Tue Apr 21 11:33:32 2020 +0200

    Add a blacklist_types argument to object_dicts() and objects() hypothesis strategies
    
    so one can choose not to generate some of the object types.
    
    Blacklist "origin_visit_status" by default to prevent breaking dependent
    packages' tests.

See https://jenkins.softwareheritage.org/job/DMOD/job/tests-on-diff/46/ for more details.

Technically, this sounds fine ;)

What is the new use case? Will we merge back the content topics into one or something?

This revision is now accepted and ready to land.Apr 21 2020, 3:43 PM

Technically, this sounds fine ;)

What is the new use case? Will we merge back the content topics into one or something?

This is needed for D3044 (all this is related to T2355). The idea is when this current stack in journal is tagged, then I can tag D3044, then I can remove all the replayer related code from the journal.
[oops]