Fix node filter to use EXISTS for exact hostname matches

[brinkcoder]

This PR fixes the node filter to use exact hostname matches instead of substring matches with LIKE, preventing issues like node=cpu001 matching fatcpu001.

Changes:

• internal/repository/jobQuery.go: Updated BuildWhereClause to use EXISTS for node.Eq and node.Contains.
• internal/repository/jobFind.go: Updated FindConcurrentJobs to use EXISTS.

[spacehamster87]

Hi there and thanks for this PR!

While the PR solves the lingering issue, the contains query fix would conflict with the current definition of the filter keyword.

This is because contains is supposed to be a LIKE operator on the DB side, as in "DB field contains this partial string".
That being said, using contains within the frontend is suboptimal in the first place, so thanks for pointing this out!

With some tweaks on the frontend side, it is possible to use both eq (exact match, should be default) and contains operators in the frontend filters, and handling them in the backend accordingly. Maybe even exchange contains for eq in all frontend use-cases.

@moebiusband73 : I would suggest changing the target branch to dev, so I can adapt the frontend to the requested changes there instead of master.

[brinkcoder]

You are absolutely right. I changed the contains to a LIKE operator.

This change repairs the filtering for Resources but breaks the Concurrent Job List again (first commit had Concurrent List right but filtering was broken).

[moebiusband73]

Hi, we need to review and adopt other things for this. Can you change the target branch to the dev branch? Otherwise I can cancel the pull request and we can implement this based on what you provided.
What do you think?
Best, Jan

[brinkcoder]

Hi, I thought you had to change the branch. Just noticed that I can do it myself.

[spacehamster87]

Thanks - I will merge now and fix the frontend issue