Project

General

Profile

Actions

Bug #9860

open

Should features_smart_proxies have a primary key?

Added by Martin Jackson about 9 years ago. Updated about 9 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Database
Target version:
-
Difficulty:
Triaged:
Fixed in Releases:
Found in Releases:

Description

I'm not sure exactly what happened, but I have the same smart proxy showing in features three times, and it shows up in some strange places and has some unusual consequences in the UI.

Here's my raw data:

foreman=# select * from features_smart_proxies ;
 smart_proxy_id | feature_id 
----------------+------------
              1 |          5
              1 |          6
              1 |          5
              1 |          6
              1 |          5
              1 |          6
(6 rows)

foreman=# \d+ features_smart_proxies ;
                    Table "public.features_smart_proxies" 
     Column     |  Type   | Modifiers | Storage | Stats target | Description 
----------------+---------+-----------+---------+--------------+-------------
 smart_proxy_id | integer |           | plain   |              | 
 feature_id     | integer |           | plain   |              | 
Foreign-key constraints:
    "features_smart_proxies_feature_id_fk" FOREIGN KEY (feature_id) REFERENCES features(id)
    "features_smart_proxies_smart_proxy_id_fk" FOREIGN KEY (smart_proxy_id) REFERENCES smart_proxies(id)
Has OIDs: no

In my selection screens, the name of the smart proxy shows up three times (it doesn't matter which one I pick). Similarly, the "Smart Proxies" section of "About" shows cirdan.minas.tirith Puppet, Puppet CA, Puppet, Puppet CA, Puppet, and Puppet CA OK.

I suspect when I remove the extra rows, everything will normalize; but it seems the duplicates should not have gotten there in the first place.

This is in release 1.8.0-RC1.

Actions #1

Updated by Dominic Cleal about 9 years ago

  • Description updated (diff)
  • Category set to Database

There should be a unique index in features_smart_proxies over the (smart_proxy_id, feature_id) columns I'd say, there's no reason to have dupes. The associate_features method in SmartProxy should also de-dupe the list of features just to ensure we don't try and add them too.

Actions

Also available in: Atom PDF