Generate package property during migration when no provided APIs.#742
Generate package property during migration when no provided APIs.#742benluddy wants to merge 1 commit into
Conversation
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: benluddy The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-ci
Bot
added
the
approved
Codecov Report
@@ Coverage Diff @@
## master #742 +/- ##
==========================================
+ Coverage 50.19% 50.29% +0.09%
==========================================
Files 100 101 +1
Lines 8531 8530 -1
==========================================
+ Hits 4282 4290 +8
+ Misses 3421 3416 -5
+ Partials 828 824 -4
Continue to review full report at Codecov.
|
|
does editing the existing migration make sense? don't we need to handle dbs already past this version? |
|
That's my question too. Properties are supposed to be opaque to the catalog, so it's also not great to go in and start generating properties after-the-fact as part of a later migration. Information is sort of implicitly lost after version 9, because we can no longer distinguish between the properties that were generated automatically as part of the migration versus a set of properties that the catalog maintainer may have specifically curated. |
All entries beginning with schema version 9 should have at least one property -- a generated package property. This did not occur for catalog entries that had no provided APIs. The existing migration is updated to fix the bug, and a new migration is added to retroactively generate the package property for databases that have already applied the existing migration. Signed-off-by: Ben Luddy <bluddy@redhat.com>
benluddy
force-pushed
the
properties-migration-without-providedapis
branch
from
b3bf33c to
eb91604
Compare
| Up: func(ctx context.Context, tx *sql.Tx) error { | ||
| if _, err := tx.ExecContext(ctx, ` | ||
| INSERT INTO properties(type, value, operatorbundle_name, operatorbundle_version, operatorbundle_path) | ||
| SELECT DISTINCT :property_type, json_object('packageName', channel_entry.package_name, 'version', operatorbundle.version), operatorbundle.name, operatorbundle.version, operatorbundle.bundlepath |
|
With operator-framework/operator-lifecycle-manager#2291 merged, plus the existing package property inference feature, I don't think there is any pressure to make this change. |
3 participants
All entries beginning with schema version 9 should have at least one
property -- a generated package property. This did not occur for
catalog entries that had no provided APIs.
The existing migration is updated to fix the bug, and a new
migration is added to retroactively generate the package property for
databases that have already applied the existing migration.