| Age | Commit message (Collapse) | Author |
|---|
|
License the software with the GNU AGPLv3+ with the exception of the
'aquatic-prime' and 'paddle' libraries and 'aquatic-prime' binary, which
are licensed under the GNU GPLv3+.
|
|
Got this error from the production MySQL server:
(details: Error 1235: This version of MySQL doesn't yet support
'multiple triggers with the same action time and event for one table')
Change our triggers so we only have one for `BEFORE INSERT`.
|
|
Ended up with this error when running my migrations against the
production server:
error: migration failed in line 0: BEGIN;
CREATE TABLE purchasers (
id INT AUTO_INCREMENT PRIMARY KEY,
name VARCHAR(255) NOT NULL,
email VARCHAR(255) NOT NULL,
secret VARCHAR(255),
created_at DATETIME NOT NULL DEFAULT UTC_TIMESTAMP(),
updated_at DATETIME NOT NULL DEFAULT UTC_TIMESTAMP()
);
CREATE TRIGGER purchasers_updated_at
BEFORE UPDATE
ON purchasers FOR EACH ROW
SET NEW.updated_at = UTC_TIMESTAMP();
COMMIT;
(details: Error 1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'UTC_TIMESTAMP(),
updated_at DATETIME NOT NULL DEFAULT UTC_TIMESTAMP()
);
CR' at line 6)
Using MySQL 5.6.34 in production and MariaDB 10.3.10 locally. Guess you
can't use `DEFAULT UTC_TIMESTAMP()` there.
To use `UTC_TIMESTAMP()`, create a couple new triggers to set the
timestamp in the `created_at` and `updated_at` columns.
|
|
Running
$ mysql -u user dome_key < 20181109031633_create_purchasers.up.sql
worked just fine, but running the migration through 'migrate' produced
this error:
(details: Error 1064: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'DELIMITER $$
CREATE TRIGGER purchasers_updated_at
BEFORE UPDATE
ON purchasers FO' at line 1)
Probably the same problem that 'migrant' had, but it just didn't give me
an error message.
After having to fiddle and mess around with different parts of the
migration for a while, it finally turned out that the `DELIMITER` seemed
to be the problem.
Got rid of it as well as the `BEGIN`/`END` that depended on it. Looks
like our timestamp updater still works even without `BEGIN`, though, so
that's good. When I had first written the code, I figured I should use
`BEGIN` because that was how it was written in a couple examples I had
seen.
|
|
Switched migration runners from https://crates.io/crates/migrant to
https://github.com/golang-migrate/migrate .
|
|
A database table to hold purchaser information so we can re-generate
licenses in case purchasers lose their license keys.
Needed to use a trigger to update the `updated_at` field on `UPDATE` as
you can't do `ON UPDATE UTC_TIMESTAMP()` in the column definition
> You can not specify UTC_TIMESTAMP as default to specify automatic
> properties
(https://dba.stackexchange.com/questions/20217/mysql-set-utc-time-as-default-timestamp/21619#21619)
Weirdly, the trigger isn't working when applying the migration with
$ migrant apply
but it is working when running
$ mysql -u user dome_key < migrations/20181108234653_create-purchasers/up.sql
Not sure what's going on there, but 'migrant' appears to have trouble
realising there are errors coming back from MySQL and executes the
migrations regardless. It also doesn't print syntax error messages from
MySQL which is very inconvenient. Migrant seemed to be the most advanced
migration CLI on crates.io, and I was hoping to use a Rust program for
this, but for simplicity, I'm thinking I'll have to go with a different
migration runner. Considering https://github.com/golang-migrate/migrate.
|
