Adding global and per-repo settings to Kallithea

[Mads Kiilerich]

On 05/19/2015 02:04 PM, Thomas De Schampheleire wrote:
> 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?

Agreed.

> 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, ...

Yes, they should probably be migrated to the settings table. The 
settings table is currently targeted at the Mercurial configs with a 
section (such as "ui") and a key (such as "username"). These "global" 
settings should perhaps just be in the "kallithea" section.

For per repo settings, I think we just should add a nullable repo_id 
field to the settings table and let it be null for global settings and 
set for per repo settings.

/Mads