Skip to content
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

BUG findClosestNode too slow if $node is already the matching one #4764

Open
mhsdesign opened this issue Nov 21, 2023 · 3 comments
Open

BUG findClosestNode too slow if $node is already the matching one #4764

mhsdesign opened this issue Nov 21, 2023 · 3 comments
Assignees
Labels

Comments

@mhsdesign
Copy link
Member

@nezaniel said that this query will take enormous amount of time - 5 seconds - on a raspery if $currentNode is already the site node:

$siteNode = $subgraph->findClosestNode($currentNode->nodeAggregateId, FindClosestNodeFilter::create(nodeTypes: NodeTypeNameFactory::NAME_SITE));
@mhsdesign mhsdesign added the 9.0 label Nov 21, 2023
@mhsdesign mhsdesign changed the title BUG findClosestNode to slow if $node is already matching one BUG findClosestNode too slow if $node is already the matching one Nov 26, 2023
@mhsdesign
Copy link
Member Author

We should investigate as we are about to add more usages of findClosestNode to the codebase ;)
Maybe you @kitsunet could please look into this? :D

Bernhard reconfirmed that

we should and it was rather awful

^^

@kitsunet
Copy link
Member

Yep will do, sounds nasty!

@kitsunet kitsunet self-assigned this Mar 20, 2024
@ahaeslich ahaeslich moved this to In Progress 🚧 in Neos 9.0 Release Board Sep 13, 2024
@mhsdesign
Copy link
Member Author

Also @dlubitz and me wondered why we dont use LIMIT=1 and rather map all rows to nodes and just return the first one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: Blocked
Development

No branches or pull requests

2 participants