Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DM-26680: Schema change integration branch #371

Merged
merged 28 commits into from Sep 26, 2020
Merged

Conversation

timj
Copy link
Member

@timj timj commented Sep 10, 2020

No description provided.

TallJimbo and others added 25 commits September 26, 2020 01:20
As all datasets are in a RUN collection, this both avoids duplicates
and prevents triggering the limitation on CALIBRATION collections in
queryDatasets in this common case.
This will ultimately need more flexibility in how to accept dataset
constraints, rather than just pulling down everything in a dataset
type + collection combination, but that is blocked by DM-26692.
This was accidentally disabled by moving the code out of core.
This allows old export files to be read, but assumes all dataset types
in them have isCalibration=False, which may not be correct.
The "perma" prefixes for these dataset type names made a bit of sense
originally because they were attached to "flat" and "bias" dataset
types that didn't have a way to be associated with a validity range
but otherwise resembled the typical versions of those datasets.  But
now we're changing how validity ranges are associated with datasets,
and there will nothing to distinguish them from the usual datasets,
and hence it makes sense to drop that prefix.
The Butler.import_ method never uses the run passed to the Butler at
construction, and hence it makes no sense as a command-line argument,
let alone a required one.  Imported datasets always land in the
collections specified in the export file.
This seems redundant right now, but it provides us some backwards
compatibility insulation against changes to how we
name those tables or encode dimensions in the  future.
There will soon be at least one more kind of dynamic table, so
that's no longer an appropriate name for this one.
Now that most fields are TEXT the test is meaningless.
General query support for these collections does not yet exist, but is
blocked by a bigger overhaul of the query system; we'll work around
this in QuantumGraph generation in pipe_base for now.
This helps us spot and report inconsistent definitions in
PipelineTasks.
I'm not certain this is the right place for this logic, but the
huge simplification it provides for ci_cpp_gen3 tests (which will carry
over directly to interactive CPP validation work) suggests that it
belongs somewhere in daf_butler.
timj and others added 3 commits September 26, 2020 01:20
DM-26629: switch to calibration collections and remove calibration_label
This ideally would have been merged with the previous version update
prior to the DM-26629 merge, but I forgot, that merge has happened,
and so have other DM-26629 merges to master, so it's time to get this
branch on master, too.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants