We've seen a few cascading errors (e.g. comment.activityId would be non
nullable but cascade behavior is set to "set null"). I think it's safer
if we have to explicitly chose the deletion behavior it every time.
Especially since Postgres default to "No action" while we defaulted to
"Set Null", which is confusing.
In the future we will most likely introduce a second param
`onSoftDelete` in the decorator
Foreign table id cannot be a foreign key of a base table. But the
current code use foreign keys to link object metadata with activities,
events... So we will:
- create a column without creating a foreign key
- add a comment on the table schema so pg_graphql sees it as a foreign
key
This PR:
- refactor a bit object metadata service so the mutation creation is
separated into an util
- adds the mutation creation for remote object relations
- add a new type of mutation to create a comment
---------
Co-authored-by: Thomas Trompette <thomast@twenty.com>
* fix: sever not throwing when enum contains two identical values
* fix: enum column name cannot be change
* fix: put field create/update inside transactions
* fix: check for options duplicate values front-end
* fix: missing commit transaction
