Skip to content
This repository has been archived by the owner on Apr 27, 2022. It is now read-only.

Enforce unique contraints on object names/labels in the database. #971

Merged
merged 11 commits into from
Mar 16, 2018

Conversation

xuhang57
Copy link
Contributor

@xuhang57 xuhang57 commented Mar 7, 2018

Fix: #946

Potentially, we should think about whether there are any other constraints.

And this might break lots of tests. Consider this is an on-going implementation

@xuhang57
Copy link
Contributor Author

xuhang57 commented Mar 7, 2018

Some help would be much appreciated.

I am suspecting that because this is called many time:

(api.node_register, ['new_node'], {'obm': {

so the node name is not unique in the CI database?

hil/model.py Outdated
@@ -58,7 +58,7 @@ class Nic(db.Model):
"""a nic belonging to a Node"""

id = db.Column(BigIntegerType, primary_key=True)
label = db.Column(db.String, nullable=False)
label = db.Column(db.String, unique=True, nullable=False)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not actually supposed to be unique; it's scoped to the node, but two nodes may have nics with the same name.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oops, I should've put it in the class Node

@coveralls
Copy link

Pull Request Test Coverage Report for Build 1693

  • 1 of 1 (100.0%) changed or added relevant line in 1 file are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage remained the same at 59.338%

Totals Coverage Status
Change from base Build 1686: 0.0%
Covered Lines: 2097
Relevant Lines: 3534

💛 - Coveralls

@coveralls
Copy link

coveralls commented Mar 8, 2018

Pull Request Test Coverage Report for Build 1729

  • 11 of 19 (57.89%) changed or added relevant lines in 3 files are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage decreased (-0.07%) to 59.273%

Changes Missing Coverage Covered Lines Changed/Added Lines %
hil/migrations/versions/264ddaebdfcc_make_labels_unique.py 6 14 42.86%
Totals Coverage Status
Change from base Build 1686: -0.07%
Covered Lines: 2103
Relevant Lines: 3548

💛 - Coveralls

@zenhack
Copy link
Contributor

zenhack commented Mar 8, 2018

Could you also write a migration script? Other than that, LGTM.

@naved001
Copy link
Contributor

naved001 commented Mar 9, 2018

project names, switch names, network names are unique too.

# revision identifiers, used by Alembic.
revision = '264ddaebdfcc'
down_revision = '89ff8a6d72b2'
branch_labels = ('hil')
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You'll want a trailing comma here; this is supposed to be a tuple.

@naved001 naved001 requested a review from ianballou March 14, 2018 15:17
@@ -287,7 +287,7 @@ ALTER SEQUENCE nic_id_seq OWNED BY nic.id;

CREATE TABLE node (
id integer NOT NULL,
label character varying NOT NULL,
label character varying NOT NULL UNIQUE,
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Naved and Jeremy suggested that this is not the place that does the migration tests. And the question now is how we can increase the test coverage? Or, where do we do the migration tests?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We shouldn't ever be modifying this file; the whole point of the tests is to verify that we can cleanly upgrade from an old database schema; this is a snapshot of a database we should be able to upgrade from. What you've done here is manually modify the old schema.

The actual tests are in hil/migrations.py.

The missing coverage in upgrade is incorrect; we're definitely running that in the migration tests (and it seems to be erroneously missing from all of the other scripts as well). downgrade() is really untested, and we basically haven't done testing with downgrading databases at all.

My inclination is to:

  1. Figure out why the upgrade function doesn't look like it's covered
  2. Open a separate issue about the fact that we're not testing downgrade() anywhere. Honestly, I'm not sure it's worth the effort to properly support database downgrades, and we've only been adding the function at all because alembic expects it. But we should discuss the issue.

I'm fine opening separate issues for both of these and just overriding the coveralls warning for now.

@naved001
Copy link
Contributor

Honestly, I'm not sure it's worth the effort to properly support database downgrades, and we've only been adding the function at all because alembic expects it.

I agree.

@zenhack
Copy link
Contributor

zenhack commented Mar 16, 2018

I'm happy. If everyone's in agreement re: coveralls we can just merge.

@naved001
Copy link
Contributor

Cool, merging then.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants