You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now createMissingTablesAndColumns silently fails if it's unable to do some column/table change.
In order to make this library more useful in mature production flows with database migrations, IMO exposed should do it's best to warn against potential inconsistencies in the database when compared to the exposed table definitions.
For e.g: If createMissingTablesAndColumns fails, then the server will crash at runtime. This is clearly unwanted behavior.
Here are some ideas:
Show detailed INFO logs about what columns were changed and how
Log a WARN when exposed fails to make a change
Have some sort of sanity check (e.g SchemaUtils.checkCRUDfor(Table1, Table2)), so that we can be sure that at least CRUD operations on table rows are happening correctly, further strengthening confidence that some small column change wasn't missed somewhere, and we'd only find out in production.
Maintain some sort of schema database/table (like exposed's internal representation of database states that can be used to compare against when exposed is run again with conflicting table/column definitions => This would be a good prompt for the developer that they probably missed migrating something)
The text was updated successfully, but these errors were encountered:
Right now
createMissingTablesAndColumns
silently fails if it's unable to do some column/table change.In order to make this library more useful in mature production flows with database migrations, IMO exposed should do it's best to warn against potential inconsistencies in the database when compared to the exposed table definitions.
For e.g: If
createMissingTablesAndColumns
fails, then the server will crash at runtime. This is clearly unwanted behavior.Here are some ideas:
SchemaUtils.checkCRUDfor(Table1, Table2)
), so that we can be sure that at least CRUD operations on table rows are happening correctly, further strengthening confidence that some small column change wasn't missed somewhere, and we'd only find out in production.The text was updated successfully, but these errors were encountered: