🐞 Fix db config persistence unique constraint conflict #5846
Conversation
tuliren
changed the title
tuliren
force-pushed
the
liren/fix-db-config-persistence-conflict
branch
from
f3053a7
to
cbb15fd
Compare
| @@ -364,7 +358,8 @@ void updateConfigsFromSeed(DSLContext ctx, ConfigPersistence seedConfigPersisten | |||
| * repository name instead of definition id because connectors can be added manually by | |||
| * users, and are not always the same as those in the seed. | |||
| */ | |||
| private Map<String, ConnectorInfo> getConnectorRepositoryToInfoMap(DSLContext ctx) { | |||
| @VisibleForTesting | |||
| Map<String, ConnectorInfo> getConnectorRepositoryToInfoMap(DSLContext ctx) { | |||
There was a problem hiding this comment.
shouldn't this return the info keyed by definition? connector repository is not guaranteed to be a primary key. Or at least maybe it should return a multimap?
There was a problem hiding this comment.
No, we cannot key it by definition. The purpose is to upgrade the connector version, and the version is included in the definition. If we key by definition, we cannot check which definition needs the upgrade efficiently.
Why the connector repository is not unique? Do we allow multiple versions of repos in the same workspace? That seems chaotic.
There was a problem hiding this comment.
fair points, let's resolve after the weekend. Enjoy the long weekend!
There was a problem hiding this comment.
I guess it also makes sense for different connectors to have the same repository with different names. In that case, I can change it to a multi-map.
Sure, this can wait after the weekend.
What
airbyte_configstable.