Opened 6 years ago

Closed 5 years ago

#3075 closed defect (wontfix)

Build Properties always have an extra 'id' row

Reported by: Ben Owned by:
Priority: major Milestone: 0.9.0
Version: master Keywords:


This issue to continue the discussion started there:

One of the immediately visible trouble of the current solution is that an 'id' row is always added in the Build properties.

Change History (7)

comment:1 Changed 6 years ago by Ben

  • Milestone changed from undecided to 0.9.0
  • Type changed from undecided to defect
  • Version changed from 0.8.9 to master

I do believe that we have a collection here. An unordered collection.

But don't calling that a collection is wrong. I'm working on a PR to make it a list of {name: , value: , source: } . I believe this is the way to go. I believe one of the trouble is already on the server-side, that the current dict is embedded in a list.

comment:2 Changed 6 years ago by dustin

Can you clarify the problem? Do you mean an id column (in the DB)? Or a field in the data API?

From a REST perspective, I think we could go one of two ways: make every property an entity (in which case, an id makes sense), then deal with the list as a collection (DELETE by id, etc.). Or, treat a build's properties as a single entity that is "replaced" as a unit (even to add/remove/update a single property).

comment:3 Changed 6 years ago by Ben

The id property is not a field in the data API, and not a row in the DB. It's just there when we try to iterate over the dictionary (in javascript) we got from the data endpoint.

This illustrates the impracticability of iterating over a keyed-by-name dictionary in javascript.

Hence my proposal of transforming that array of one dictionnary keyed by property name into an array of dictionnaries (name, value, source).

comment:4 Changed 6 years ago by Ben

I mentioned that I was working on a PR to make the properties available from the data interface as list of dict.

I got lost. Properties are everywhere. I obviously don't want to change their internal representation, As the trouble seems to be javascript (and its non distinction between Object and dict), only that part needs some work. But the validators for instance are used everywhere ... As soon as I change one, the whole test suite is collapsing. If I don't change it, the test suite is also (luckily) not passing ... I need to get a better overview of the work needed there before I give another try at that ...

comment:5 Changed 6 years ago by dustin

Is the object/dict distinction so difficult to overcome? There are ways to iterate over the "real" keys of an object in JS (omitting methods from the Object prototype).

comment:6 Changed 6 years ago by dustin

I'm putting this under the umbrella of #2622, which proposes to handle properties better and more consistently.

comment:7 Changed 5 years ago by dustin

  • Resolution set to wontfix
  • Status changed from new to closed

I think this is just a JS issue, rather than a BB issue.

Note: See TracTickets for help on using tickets.