There is some known variation between the various context classes invoked by metadata populate --context. Although the signatures of the constructor is maintained in sync, many of the options are really targetted at one context only.
DeleteMapAnnotationContext is probably the most obvious example. Unlike the other contexts, it uses the loops and ms options for the graph operation on the server. In addition, populate --context deletemap feels a bit contradictory from a semantic perspective.
A proposal would be to:
separate the DeleteMapAnnotationContext API the other population contexts, eventually migrating it to a separate module
deprecate metadata populate --context deletemap and replace it by a more explicit metadata delete subcommdn (maybe even metadata delete --bulkmap to mirror the populate command)
fix the default deletion command behavior to properly handle infinite waiting
metadata delete is sufficiently broad that it might help to drive the renaming here. e.g.: bulkmap delete and mapannotation delete or metadata delete maps etc.
See https://github.com/ome/omero-metadata/pull/11#issuecomment-420939255
There is some known variation between the various context classes invoked by
metadata populate --context
. Although the signatures of the constructor is maintained in sync, many of the options are really targetted at one context only.DeleteMapAnnotationContext
is probably the most obvious example. Unlike the other contexts, it uses theloops
andms
options for the graph operation on the server. In addition,populate --context deletemap
feels a bit contradictory from a semantic perspective.A proposal would be to:
DeleteMapAnnotationContext
API the other population contexts, eventually migrating it to a separate modulemetadata populate --context deletemap
and replace it by a more explicitmetadata delete
subcommdn (maybe evenmetadata delete --bulkmap
to mirror the populate command)