Hi, I would like to get some clarification/discussion on adding new settings to Kallithea, both global and per-repo settings.
For global settings, there is a 'settings' table that has one row per setting, each setting having a name, value and type. This is a nice and simple implementation. However, it seems that when new settings have been added in the past, there was always a database migration associated with it. This migration is not that big of a deal, but still doesn't seem necessary to me. When a setting is not present in the database, the default should be applied instead (at runtime, without changing the db). When a setting is first changed, the database is updated with the right setting. Alternatively, the setting is defaulted in the database when it is first used and found to be missing from the database. Does this make sense to you? Do you agree that a database migration is not necessary? Regarding per-repo settings: is this currently implemented in some way? If so how? If not, how should we best implement this? In the repositories table, there are several columns that could be considered as per-repo setting, but it is not very nice to keep adding columns for every new per-repo setting. Such columns include landing_revision, enable_locking, ... Thanks for the feedback, Thomas _______________________________________________ kallithea-general mailing list [email protected] http://lists.sfconservancy.org/mailman/listinfo/kallithea-general
