Jeremy,

I observed the same thing when I upgraded my instance of Traffic Ops. It
had duplicated "tm.toolname" as a key. +1 on the proposal.

Steve

On Thu, Aug 24, 2017 at 12:04 PM, Jeremy Mitchell <mitchell...@apache.org>
wrote:

> IMO there seems to be an inherent flaw with global parameters and that flaw
> is exposed in via seeds.sql.
>
> Let's use an example.
>
> There is a global parameter called tm.toolname with a seeded value of
> 'Traffic Ops' (
> https://github.com/apache/incubator-trafficcontrol/blob/
> master/traffic_ops/app/db/seeds.sql#L39
> )
>
> Obviously, the intention of this parameter is that you can change it to fit
> your needs. Maybe you want to change it to "Traffic Mops".
>
> However, when seeds.sql runs again (on upgrade for example), you will end
> up with a duplicate tm.toolname parameter because the unique constraint on
> the parameter table is applied to name + config_file + value.
>
> For "global" parameters, the unique constraint should really be on name +
> config_file because, really, why would you want more than 1 global
> parameter?
>
> So we have a table (parameters) where some parameters the unique constraint
> should be name + config_file + value (which makes perfect sense if you
> think about how parameters are used with profiles) and other parameters
> (global) where the unique constraint should be name + config_file...
>
> Anyhow, after saying all of that....I think the solution (or a solution) is
> to modify seeds.sql to first run a query (select count) for global
> parameters to ensure that they are not already there before inserting
> them....
>
> I'll create a jira for that if there is no objections.
>
> jeremy
>

Reply via email to