Opened 9 years ago

Closed 9 years ago

#967 closed defect (fixed)

nested lists in configuration doesn't work

Reported by: jelte Owned by: jelte
Priority: medium Milestone: Sprint-20110531
Component: configuration Version:
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: N/A
Sub-Project: Core Feature Depending on Ticket:
Estimated Difficulty: 2.0 Add Hours to Ticket:
Total Hours: 0 Internal?: no

Description

problem in find_spec_part results in the second list info not being found (which has two symptoms, you can find default values, and you can't set them through bindctl)

(found this problem while working on #736, but since it seems quite separate I made a new ticket for this)

Subtickets

Change History (6)

comment:1 Changed 9 years ago by jelte

  • Owner changed from jelte to UnAssigned
  • Status changed from new to reviewing

refactored the code a bit, code existed for this specific case but in this combination it wasn't called, so i pulled it out and made it into a few separate functions

(and added a test, naturally)

comment:2 Changed 9 years ago by vorner

  • Owner changed from UnAssigned to vorner

comment:3 Changed 9 years ago by vorner

  • Owner changed from vorner to jelte

Hmm, I'm just wondering, sometimes the input of the function is a dict for map element and sometimes list (I know they are inside each other, and I see the function looks like it should correctly handle both types of input). I'm just wondering, is it really called with both possibilities? Where does it come from?

comment:4 Changed 9 years ago by jelte

  • Owner changed from jelte to vorner

Yes; but it kinds of depend where the previous 'iteration' left it (or whether it's the first). For instance, the initial type is a list (of dicts), and so is a map specification. But the element containing said specification is itself a dict.

This did remind me to run coverage again, and one of the paths wasn't hit in the tests. So I added another test (and found a potential problem due to the second branch not checking the name).

This part has gotten quite hairy, and I am thinking about cleaning this up (by not passing around bare structures but making some nice Specification classes that can be serializable into JSON. As we are planning on extending the set of types the current code would only become more complicated)

comment:5 Changed 9 years ago by vorner

  • Owner changed from vorner to jelte

OK, this thing seems to be correct (and I must admit I did overlook it the first time as well).

About the encapsulating, it might make sense (but only for the specs, not for the config data, I find it handy that the config data are just dicts and lists). But maybe for another ticket?

Anyway, let's merge this, shall we?

comment:6 Changed 9 years ago by jelte

  • Resolution set to fixed
  • Status changed from reviewing to closed

Merged, closing ticket

Note: See TracTickets for help on using tickets.