Given non-null default value to the database

[christianlupus]

Set a default (non-null) value during migration allows to use broader set of mariadb versions.

This PR is motivated by the discussion on #20.

Fixes #20

At least on my machine this allows the app to be installed successfully. I think this should not affect any future versions as it simply set a feasible (in terms of the DDL) default value, which seems reasonable.

It has to be verified by the main developer that the default value of 0 is a valid solution: That is: Is the expires column really a unix timestamp or some other format? My understanding is yes (which is safe) but I am not 100% sure from reading through the code.

[ChristophWurst]

This should be fine indeed. To verify we should set https://github.com/ChristophWurst/twofactor_admin/blob/66c91e16dbcc6fb046b966264d7acf964821b6d2/.travis.yml#L21 to 10.3. If CI passes the patch fixes #20

[ChristophWurst]

• Requires Add Nextcloud 17 compatibility #32

[christianlupus]

This should be fine indeed. To verify we should set

twofactor_admin/.travis.yml

Line 21 in 66c91e1
mariadb: '10.1'
to 10.3. If CI passes the patch fixes #20

Should I just do this or wait for inspection?

I tried it in a separate branch to check the travis tests' results. With DB=mysql there is still a problem: https://travis-ci.org/christianlupus/twofactor_admin/builds/523492593. I suspected a missing auto_increment flag in the table definition. Therefore I extended the travis script to show the SQL syntax to create the oc_twofactor_admin_codes table.
You can see, that the id field does neither have a default value nor an auto_increment flag set. This seems to be a different problem than the original issue I focused in my PR.

[ChristophWurst]

Should I just do this or wait for inspection?

Yes, please change this here.

You can see, that the id field does neither have a default value nor an auto_increment flag set. This seems to be a different problem than the original issue I focused in my PR.

Good catch. I'm fine with having a separate PR for that, but in order to mark #20 as fixed I want to have working CI checks that verify it. And as you tested, Travis won't pass on mysql/mariadb once a newer version is used.

[christianlupus]

OK, I changed the maradb version 10.3 as intended. As already stated the CI failed.

To get it running again, I added a comparably dirty hack to restore the autoincrement flag in the database. With that the CI succeeded and @ChristophWurst might want to have a look at it.

[ChristophWurst]

Squashed & rebased. Changes look good and CI is happy. Let's get this in 👍