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
_______________________________________________
kallithea-general mailing list
[email protected]
http://lists.sfconservancy.org/mailman/listinfo/kallithea-general
