BUGFIX: Don’t query for abstract nodetypes in nodedata repository

[Sebobo]

As abstract nodetypes don't (shouldn't) appear in the database it makes no sense to query them.

This is a regression that was introduced a long time ago, when the default parameter to include abstract nodetypes was added to the getSubNodeTypes method in the NodeTypeManager without adjusting the call in the NodeDataRepository->getNodeTypeFilterConstraintsForDql which relied on the previous behaviour.

The call in the method getNodeTypeFilterConstraints was fixed some years ago, but that method seems unused.

[mhsdesign]

Thank you that makes absolutely sense!

But for some reason, we willingly include the abstract nodetypes in findDescendantNodes in neos 9:

neos-development-collection/Neos.ContentRepository.Core/Classes/Projection/ContentGraph/NodeTypeConstraintsWithSubNodeTypes.php

Line 111 in 88cb1fd

$subNodeTypes = $nodeTypeManager->getSubNodeTypes($nodeTypeName, true);

I dont know why, but i think the behavior should align.

see #4532

[mhsdesign]

I forgot if you measured this but I spoke with @nezaniel about this and he said this NodeTypeName in array query shouldn’t get measurable slower if the list is longer.

but he said this about the new 9.0 implementation #4532 - I don’t know if we have a more complex query in neos 8?

[Sebobo]

I measured only the request time and I think it's not the reading time but the generation and looping.

[bwaidelich]

+1 by reading

[mhsdesign]

Makes sense ;)