- πΊπΈUnited States euk
An old ticked, but it is still relevant, and just recently caused me an issue. I spent a good chunk of time today figuring out what in the world has happened to a merge of a few
filter.format.*
config files. Turns out weights were merged somewhat incorrectly. Not sure what happened there, but while comparing those config files for ordering I found that it is really hard to see how the ordering has changed with just a diff tool. You really have to spawn a site, import configs and compare ordering of filters visually through the UI. With the weight values and without visual augmentation - go figure what is the order.I am not sure why are we so hung up on using weights?
Assuming a machine name is used for keys and the config maps are sorted by config keys - why not implement a binary tree with the reference to left and right (top and bottom) children by their machine name. This seems to solve the ordering and doesn't require storing a numeric position which apparently changes constantly and is the root of all troubles.
- There is always a root at the top - has left, first child, pointer empty,
- Leaf items will always have their right, next child, pointer empty,
- The rest is self explanatoryBenefits:
- Each item is clearly marked where in the tree it is located.
- Splitting or inserting an item anywhere in the tree will only alter the adjacent items, not the whole tree
- Reordering items in the UI and saving the configs will not alter the structure, if the final ordering is kept the sameAt least for flat structures like filter formats, fields without field groups etc - this should be really simple.
I agree. Sorting by machine name is superior. When you have weights, the weights always change, which changes them all and complicates the diffs.