Commit Graph

11 Commits

Author SHA1 Message Date
1712782cc5
[DB] Change foreign key specification to new format 2021-09-14 13:06:57 +01:00
e2e53d9a2a
[AUTOGENERATED] Update auto generated code in entities 2021-09-14 13:06:56 +01:00
460712e15e
[GIT] Change my email to the new one in all files and bump copyright year 2021-09-14 13:06:56 +01:00
Hugo Sales
3b86a46625
[DB] Rename notice to activity in notification table 2021-09-14 13:06:49 +01:00
Hugo Sales
c8e8f1f057
[ENTITY] Add Entity base class to all entities 2021-09-14 13:05:56 +01:00
Hugo Sales
51a1a1180e
[AUTOGENERATED] Update autogenerated code 2021-09-14 13:05:54 +01:00
Hugo Sales
1111ee95f1
[CORE] Data Representation and Modelling refactor 2021-09-14 13:05:53 +01:00
Hugo Sales
699f25a397
[AUTOGENERATED] Update autogenerated code 2021-09-14 13:05:51 +01:00
Hugo Sales
97b583aee7
[AUTOGENERATED] Update autogenerated code 2021-09-14 13:05:29 +01:00
Hugo Sales
5eae3dc351
[CORE][DATABASE] Replace zero dates with CURRENT_TIMESTAMP and add defaults to all 'created' or 'modified'
This commit is a port from v2's 9a515b9234 ([SCHEMA] Improve timestamp storage) to v3.

As explained by Alexei Sorokin:

Avoid the use of deprecated MariaDATABASE "zero dates" globally. If they're present
as attribute defaults somewhere, they will be replaced with NULL implicitly.
The existing "zero dates" in MariaDATABASE storage will be left intact and this
should not present any issues.

The "timestamp" type in table definitions now corresponds to DATETIME in
MariaDATABASE with "DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP", which
should be close enough to the original behaviour for compatibility purposes.
It is now the recommended type for "modified" attributes, because of the
update trigger on MariaDATABASE. But there is no such trigger implemented on
PostgreSQL as of this moment.
2021-09-14 13:05:29 +01:00
Hugo Sales
25aeac80a3
[CORE][DATABASE] Restructure the database 2021-09-14 13:05:29 +01:00