Learn more about these different git repos.
Other Git URLs
This is a follow-up of #2614.
I did a reversion of PR #1434 in PR #2782, but it is only to tolerate duplicate parent items in the changes option.
changes
in @tkopecek 's comment:
but maybe there are some cases when it makes sense (e.g. first parent with some filter option, while second without).
Maybe we could allow duplicate parents with different priorities in tag_inheritance table? But not sure if there are any usecases.
notes: right now, our DB INDEX forbids this, and readFullInheritance() function allows this (no test)
readFullInheritance()
Metadata Update from @julian8628: - Custom field Size adjusted to None
right now, our DB INDEX forbids this
Specifically, this uniqueness contraint
UNIQUE (tag_id,parent_id,active)
The tag_inheritance_by_parent index defined in the schema is not a unique index and does not forbid this.
tag_inheritance_by_parent
The use case is, as mentioned in other issues, inheriting from the same tag with different inheritance options.
For example, an admin could for example inherit from tag A with priority 1 and pkg_filter='kernel', then from tag B with priority 2, then from tag A again with priority 3 and no pkg_filter.
Even with this constraint still in place, similar situations can arise in the overall inheritance. E.g.
some-tag .F.. ├─tag_a .F.. ├─tag_b .... └─other_tag .... └─tag_a
Note that, beyond the db constraint, _writeInheritanceData assumes that parent_ids are unique. It looks up original entry with orig = data.get(parent_id). Current ability to edit or delete existing inheritance lines relies on this lookup.
_writeInheritanceData
orig = data.get(parent_id)
So, changing this is potentially tricky.
Related: #3910
PR 4000
Metadata Update from @jcupova: - Issue set to the milestone: 1.35
After several iterations in #4000, it's become clearer that this change is not only tricky, but risky as well. The current uniqueness of direct parents is longstanding, and could be assumed in external code.
The use case listed above is esoteric at best, and can be accomplished already using indirect inheritance, so there really is no need to pursue this any further. See #4000 for more info.
Metadata Update from @mikem: - Issue close_status updated to: Dropped - Issue status updated to: Closed (was: Open)
Metadata Update from @tkopecek: - Issue set to the milestone: None (was: 1.35)
Commit 3315e3c fixes this issue
This commit does not implement this feature. This feature was dropped.
Metadata Update from @mikem: - Issue status updated to: Open (was: Closed)
Login to comment on this ticket.