replace neo4j with postgres

[jamesamcl]

No description provided.

In general, to fix a useless parameter, either remove it from the method signature (and from all its call sites) or update the method body to use it meaningfully. Since we must avoid changing intended behavior and we have no specification that type should influence the query, the least invasive fix is to remove type from the traverseOutgoingEdges signature.

Concretely, in backend/src/main/java/uk/ac/ebi/spot/ols/repository/postgres/OlsPostgresClient.java, update the traverseOutgoingEdges method declaration at line 80 to drop the String type argument, leaving the remaining parameters and body unchanged. Within the snippet provided, this is the only necessary code change; imports and method body do not need adjustments. Note: callers of this method will also need to be updated elsewhere in the codebase to stop passing the removed argument, but those changes are outside the shown snippet and cannot be modified here.

In general, the best fix for a useless parameter is to remove it from the method signature and from all call sites, so the API reflects only what is actually needed. This reduces confusion for callers and prevents assumptions that the parameter influences behavior when it does not.

For this specific case, the String type parameter of traverseIncomingEdges should be removed from the method signature on line 102. Since we are only allowed to edit the shown snippet from OlsPostgresClient.java, we cannot update any external callers here; but within this file, no calls to traverseIncomingEdges are shown, so we only adjust the method declaration itself. The method body does not refer to type, so no internal changes are needed. We do not introduce any new imports or helper methods.

Concretely:

• In backend/src/main/java/uk/ac/ebi/spot/ols/repository/postgres/OlsPostgresClient.java, update the traverseIncomingEdges method’s parameter list to remove the leading String type.
• Leave the rest of the method (its use of id, edgeIRIs, edgeProps, sourceNodeProps, pageable, and searchQuery) unchanged.

To fix the problem, the unused type parameter should be removed from the method signature of recursivelyTraverseOutgoingEdges so that the method’s interface matches its actual behavior. This makes the API clearer and avoids misleading callers into thinking type affects the traversal.

The best way to do this without changing existing functionality in the shown code is:

1. Update the signature of recursivelyTraverseOutgoingEdges (line 136) to remove the String type parameter, leaving id, edgeIRIs, edgeProps, targetNodeProps, and pageable.
2. Because the method body never referenced type, no internal logic changes are required.
3. We cannot adjust any external callers because they are not shown; however, within the constraints given, we are only allowed to edit the shown snippet. So we will keep changes minimal and local to this method. (Callers in other files would, in a full refactor, need to be updated to stop passing the type argument.)

No new imports, helper methods, or additional definitions are needed; this is a pure signature simplification.

---

In general, a useless parameter should be removed from the method signature and from all call sites, unless it is required by an interface/override. Here, type in recursivelyTraverseIncomingEdges is never used, and all internal calls within this method also do not depend on it, so the best fix is to remove type from the method’s parameter list.

Concretely, in backend/src/main/java/uk/ac/ebi/spot/ols/repository/postgres/OlsPostgresClient.java, locate the declaration of recursivelyTraverseIncomingEdges around line 148 and delete the String type, parameter from its signature. The method body does not need any other changes, because type is never referenced. No new imports or helper methods are required. Note: callers elsewhere in the codebase that pass a type argument to this method will also need to be updated to remove that argument, but those edits are outside the scope of the provided snippet.

In general, a useless parameter should be either removed from the method signature and all its call sites, or actually used in the method body if it was meant to affect behavior. Here, behavior is currently independent of edgeProps, and we must not introduce new filtering logic that might change results. Therefore the least invasive, behavior‑preserving fix is to remove the edgeProps parameter from recursiveEdgeTraversal and adjust its callers accordingly so they no longer pass it.

Concretely, within backend/src/main/java/uk/ac/ebi/spot/ols/repository/postgres/OlsPostgresClient.java, we will:

• Update the signature of recursiveEdgeTraversal to remove Map<String, String> edgeProps from the parameter list.
• Update any call in this file that invokes recursiveEdgeTraversal with an edgeProps argument so that it calls the method with one fewer argument, dropping the edgeProps value. This preserves current behavior (since it was unused) and removes the static‑analysis warning.
• No additional imports, methods, or other definitions are required.

In general, a useless parameter should either be removed from the method signature (and all call sites) or used appropriately in the method body. Here, nodeProps appears to be a genuine filter parameter that should apply node-level conditions to the recursive traversal results rather than being removed.

The best fix, without changing existing functionality semantics, is to incorporate nodeProps into the dataQuery (and, where reasonable, into the recursion seed/step) by reusing the existing buildNodePropCondition helper. Since recursiveEdgeTraversal currently selects from ols_entities as alias "e" based on IDs collected in the recursive CTE, we can at least apply node property filters at that final selection step. Concretely, inside recursiveEdgeTraversal, after constructing dataQuery and before (or as part of) the .where(...) clause, we should add an .and(buildNodePropCondition("e", nodeProps)) so that any "isObsolete" filters in nodeProps are honored. This requires no new imports and uses only code already present in the file.

You only asked to see/edit code inside backend/src/main/java/uk/ac/ebi/spot/ols/repository/postgres/OlsPostgresClient.java, and the change will be localized to the recursiveEdgeTraversal method, using buildNodePropCondition that is already defined immediately above it.

In general, to fix this problem, the parsing of the numeric values should be wrapped in a try/catch that catches NumberFormatException so that any malformed numeric strings do not cause an uncaught runtime exception. The catch block should translate the error into a controlled outcome consistent with the existing method behavior.

For this specific code, the best minimal-impact fix is to keep the current logic that reads the embeddings string, trims brackets, splits on commas, and trims each token, but replace the bare Double::parseDouble mapping with an explicit lambda that wraps Double.parseDouble in a try/catch (NumberFormatException e). If any element fails to parse, we can throw a ResourceNotFoundException("entity not found"), which aligns with the method’s existing behavior when no record is found. This avoids exposing raw parsing errors to callers and maintains a simple "entity not found/invalid" contract without changing the method signature or imports.

Concretely, in backend/src/main/java/uk/ac/ebi/spot/ols/repository/postgres/OlsPostgresClient.java, within getEmbeddingVector, update the stream pipeline on lines 398–401. Replace .map(Double::parseDouble) with .map(s -> { try { return Double.parseDouble(s); } catch (NumberFormatException e) { throw new ResourceNotFoundException("entity not found"); } }). No new imports are needed because ResourceNotFoundException is already imported and Double/NumberFormatException are from java.lang.