In preparation for allowing TUs to change their votes on proposals,
we need a way to track what users vote for.
Without this, the vote decisions are stored within the related
TU_VoteInfo record, decoupled from the user who made the vote.
That being the case meant we cannot actually change a vote, because
we can't figure out what TU_VoteInfo decision columns to decrement
when the vote has changed.
You may be wondering why we aren't removing the decision columns out
of TU_VoteInfo with the advent of this new column. The reason being:
previous votes are all calculated off of the TU_VoteInfo columns, so
without a manual DB rework, relocating them to the user-related vote
records would break outcomes of old proposals. So, the plan is:
we'll solely use this column for votes from this point on to track
what decision a user made internally, which will open up TUs changing
their decision.
In addition, this migration resets all running proposals:
- all votes are deleted
- time is reset to Start when migration is run
This was necessary to put running proposals into a state that can
take advantage of the new revote system.
Signed-off-by: Kevin Morris <kevr@0cost.org>
Somehow, many aur.al records of PackageVotes do not have a valid VoteTS
value. This migration fixes that issue by setting all null VoteTS
columns to the epoch timestamp.
Signed-off-by: Kevin Morris <kevr@0cost.org>
This migration modifies the Yes, No, Abstain and ActiveTUs columns
of the TUVoteInfo table from unsigned TINYINT to unsigned INTEGER.
TINYINT supports a total of 1 byte (up to 255 trusted users). This
is quite limited and we don't spend too much more by storing a
standard 4-byte INTEGER.
Signed-off-by: Kevin Morris <kevr@0cost.org>
Some of the columns that were changed still want to be
case insensitive. Good thing our tables have nice
separation.
Signed-off-by: Kevin Morris <kevr@0cost.org>
MySql defaults to `utf8` and case insensitive collation so migrate these to case sensitive and `utf8mb4`
Closes#21
Signed-off-by: Leonidas Spyropoulos <artafinde@gmail.com>
op.drop_constraint requires a valid field to drop the constraint on.
Without this, downgrade cannot occur.
Signed-off-by: Kevin Morris <kevr@0cost.org>
This column holds a user ID issed by the single sign-on provider. For
Keycloak, it is an UUID. For more flexibility, we will be using a
standardly-sized VARCHAR field.
Signed-off-by: Lukas Fleischer <lfleischer@archlinux.org>
This way the database will get stamped, and Git will create the
`versions` directory without which Alembic won’t work.
Signed-off-by: Lukas Fleischer <lfleischer@archlinux.org>