Bug #9860
openShould features_smart_proxies have a primary key?
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.
Updated by Dominic Cleal about 10 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.