Currently, the code breaks when an admin attempts to remove the avatar_url or display_name properties of the user table.
We should allow the admin to do whatever schema changes he wants to user, without the code breaking and simultaneously be able to add new optional properties to that table.
I see two approaches for this:
1) There is an environmental variable for each optional property(e.g. avatar_url) that dictates whether the functionality related to that optional property is enabled or disable(defaults to enabled). If the user wishes to remove the optional property from the schema he must also change the env variable.
2) The code checks on startup whether the optional property(e.g. avatar_url) exists and has the correct type. If that condition is met the code will enable the functionality related to that optional property. The only caveat I see with this approach is that a user might want to have a property with the same name and type as the optional property but not the built-in functionality.
Currently, the code breaks when an admin attempts to remove the
avatar_url
ordisplay_name
properties of theuser
table.We should allow the admin to do whatever schema changes he wants to
user
, without the code breaking and simultaneously be able to add new optional properties to that table.I see two approaches for this: 1) There is an environmental variable for each optional property(e.g.
avatar_url
) that dictates whether the functionality related to that optional property is enabled or disable(defaults to enabled). If the user wishes to remove the optional property from the schema he must also change the env variable. 2) The code checks on startup whether the optional property(e.g.avatar_url
) exists and has the correct type. If that condition is met the code will enable the functionality related to that optional property. The only caveat I see with this approach is that a user might want to have a property with the same name and type as the optional property but not the built-in functionality.