-
-
Notifications
You must be signed in to change notification settings - Fork 224
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce Subtree Tags #4550
Comments
Would it be possible for a child to unset/override an inherited attribute? |
@mhsdesign not exactly, it would be the same as with the "disabled" flag today: descendant nodes all inherit the attributes, but they can set the same attribute additionally (i.e. disable a node and then disable some ancestor). It is slightly confusing, but IMO the behavior makes sense (at least for the disable/enable example) |
Hi wow thanks for this implementation ❤️ I didnt read through it yet fully - so i might have missed this - but i wanted to ask how do we want to migrate existing 9.0 projects? As far as i understand the Currently we seem to handle migrations inside the projections like here: neos-development-collection/Neos.Neos/Classes/PendingChangesProjection/ChangeProjection.php Lines 95 to 108 in e0358f6
i found this a little odd at first as i thought we would just dump the projection and rebuild it from scratch so i asked sebastian and he explained to me (on slack):
|
isn't the attribute value more an attribute type? Just read roughly over the PR and I think it might be more of a type of attribute. Also with the name attribute I would expect a type/name and a value, so lets say the attribute "topicrelation" with a value of "animals". I think that could be useful as well, but is a totally different feature. So I would rather use a different name for this here? |
@kitsunet hmm yes at first i also thought that A third thing to discuss/ask: In #3732 you suggested that one can build a subgraph for arbitrary attributes like On the other hand having this magic string 'disabled' hardcoded at many places might not be cool at all too - so maybe because this is a "core" attribute we could introduce a constant or create factory methods for this too. |
@mhsdesign @kitsunet thanks for your early feedback!
Yes, that's missing still, but we can probably address that in the projection
I called it "tag" at first, but that was also misleading.. Maybe we can find a better name.
That's just WIP, it should definitely be a custom type or constant |
It turns out, with this approach making the tags (aka "attributes", "labels", but I'll stick to "tag" from now on) available in the For the record: SET @tag = '$.disabled';
SET @nodeId = 'a1';
# ADD TAG
UPDATE
relation
SET
tags = JSON_INSERT(tags, @tag, false)
WHERE parentnodeanchor IN (
WITH RECURSIVE cte (id) AS (
SELECT childnodeanchor FROM relation WHERE childnodeanchor = @nodeId AND JSON_EXTRACT(tags, @tag) IS NOT TRUE
UNION ALL
SELECT
r.childnodeanchor
FROM
cte
JOIN relation r ON r.parentnodeanchor = cte.id
WHERE
NOT JSON_CONTAINS_PATH(r.tags, 'one', @tag)
)
SELECT id FROM cte
);
UPDATE
relation
SET
tags = JSON_SET(tags, @tag, true)
WHERE
childnodeanchor = @nodeId;
# REMOVE TAG
SELECT @inherited := EXISTS (SELECT
p.tags
FROM
relation p
JOIN relation r ON r.parentnodeanchor = p.childnodeanchor
WHERE
r.childnodeanchor = @nodeId
AND JSON_CONTAINS_PATH(p.tags, 'one', @tag)
LIMIT 1);
UPDATE
relation
SET
tags = IF(@inherited, JSON_SET(tags, @tag, false), JSON_REMOVE(tags, @tag))
WHERE childnodeanchor IN (
WITH RECURSIVE cte (id) AS (
SELECT CAST(@nodeId AS CHAR(100)) id
UNION ALL
SELECT
r.childnodeanchor
FROM
cte
JOIN relation r ON r.parentnodeanchor = cte.id
)
SELECT id FROM cte
); => tags are represented as JSON object in the form: {
"<tagName>": <explicit>
} for example: {
"disabled": true,
"someInheritedTag": false
} |
mmm, ok but that works only for tags that actually are pertaining to a hierarchical relation then. Which I guess is fine for the use cases we have right now? |
What do you mean? That means, that tags are always effective recursively – but this is a requirement anyways and would be the same no matter which approach we take |
@bwaidelich i might have misinterpreted the original idea, but I thought originally you wanted to employ "tag" edges alongside the hierarchy edges, which would mean in theory they could also run along reference edges or anything else really. Which might be super useful int he future, but then I also would first have to come up with a specific usecase for that. Could be an extension point though. Either way that was my line of thinking and how it's now presented would not allow that. Fine by me just wanted to point out my thoughts. |
This is a follow-up to the Subtree Tags introduction (#4659) that removes the now unsued `VisibilityConstraints::isDisabledContentShown()` *Note:* The implementation of this method was incorrect but instead of fixing that I decided to remove it since we should no longer rely on this and instead refer to the public `VisibilityConstraints::tagConstraints` field Related #4550
Currently we use so called "restriction edges" under the hood in order to keep track of disabled nodes.
They have some characteristics that would make them very useful to be used security / filter related features (see #3732).
Ideas
DisableNodeAggregate
commands emit a (new) event typeNodeAggregateAttributeWasAdded
NodeAggregateWasDisabled
events to the new event typeEnableNodeAggregate
(emitsNodeAggregateAttributeWasRemoved
and upcasting forNodeAggregateWasEnabled
events)As a result, projections would have to be adjusted from
to something like
Questions / Discussions
I wonder whether the current behavior of the restriction edges might lead to confusion. E.g.: You could tag a node and that attribute would be "inherited" to all descendants. But you could additionally tag descendants with the same attribute.. Maybe just a matter of good documentation.
Related: #3732
The text was updated successfully, but these errors were encountered: