#2804 allow duplicate parents with different priorities in the same inheritance level
Closed: Dropped 2 days ago by mikem. Opened 2 years ago by julian8628.

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.

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)

Metadata Update from @julian8628:
- Custom field Size adjusted to None

2 years ago

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.

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.

So, changing this is potentially tricky.

Metadata Update from @jcupova:
- Issue set to the milestone: 1.35

2 months ago

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)

a month ago

Metadata Update from @tkopecek:
- Issue set to the milestone: None (was: 1.35)

a month ago

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)

2 days ago

Metadata Update from @mikem:
- Issue close_status updated to: Dropped
- Issue status updated to: Closed (was: Open)

2 days ago

Login to comment on this ticket.

Metadata