Add wrapper around node and connection #9

Closed
opened 2026-05-20 19:23:02 +00:00 by linarphy · 2 comments
Owner

The goal is to avoid user of this library to use pattern like

online_state = node.state.online
if not isinstance(online_state, NodeIsOnline):
    raise TypeError
connections = online_state.outgoing_connections

This already exists with Node.connect which is a wrapper around Node.state.online.connect and raise an error if the node is not online.

These pattern happens right now when we want:

  • fetch connections of a given node
  • ? I think that’s it

There is two solutions I think of:

  1. add Node.get_neighbors_by_node_type(type_), Node.get_neighbors_by_node_data(filter_), etc…
  2. add utils.get_neighbors_by_node_type(node, type_), etc…
  3. add a query builder, to answer request with better function than these. This could be a SPARQL engine !

I prefer option 1 over option 2. Ultimately, I feel like option 3 is the future proof best answer. We shouldn’t need to have that many function to fetch for neighbors. Having a query engine that can express exactly what we want is better.

The goal is to avoid user of this library to use pattern like ```py online_state = node.state.online if not isinstance(online_state, NodeIsOnline): raise TypeError connections = online_state.outgoing_connections ``` This already exists with `Node.connect` which is a wrapper around `Node.state.online.connect` and raise an error if the node is not online. These pattern happens right now when we want: - fetch connections of a given node - ? I think that’s it There is two solutions I think of: 1. add `Node.get_neighbors_by_node_type(type_)`, `Node.get_neighbors_by_node_data(filter_)`, etc… 2. add `utils.get_neighbors_by_node_type(node, type_)`, etc… 3. add a query builder, to answer request with better function than these. This could be a SPARQL engine ! I prefer option 1 over option 2. Ultimately, I feel like option 3 is the future proof best answer. We shouldn’t need to have that many function to fetch for neighbors. Having a query engine that can express exactly what we want is better.
linarphy added the due date 2026-05-29 2026-05-20 19:24:57 +00:00
Author
Owner

This can be interesting: https://github.com/cdhx/SPARQL_parse, but not well packaged and quite old. Can be a starting point.

This can be interesting: https://github.com/cdhx/SPARQL_parse, but not well packaged and quite old. Can be a starting point.
Author
Owner

Option 1 done, will work on option 3 later.

Option 1 done, will work on option 3 later.
Sign in to join this conversation.
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

2026-05-29

Blocks
#2 Add examples use
linarphy/galaxy-graph
Reference
linarphy/galaxy-graph#9
No description provided.