-
Notifications
You must be signed in to change notification settings - Fork 54
Stream topology endpoint #138
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
Stream topology endpoint #138
Conversation
knutwalker
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall, looks good.
I have one remark about the default type, Github says there is a conflict, and TC says
graphdatascience/query_runner/arrow_query_runner.py:123: error: Argument 3 to "_run_arrow_property_get" of "ArrowQueryRunner" has incompatible type "Set[Any]"; expected "Dict[str, Any]"
| return self._query_runner.run_query(query, params).squeeze() # type: ignore | ||
|
|
||
| @compatible_with("stream", min_inclusive=ServerVersion(2, 2, 0)) | ||
| def stream(self, G: Graph, relationship_types: Strings = ["*"], **config: Any) -> DataFrame: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using mutable values as default is a common trap in Python, as the materialized default value is the same shared instance, not a new list. The common pattern is to use something like
| def stream(self, G: Graph, relationship_types: Strings = ["*"], **config: Any) -> DataFrame: | |
| def stream(self, G: Graph, relationship_types: Strings = None, **config: Any) -> DataFrame: | |
| if relationship_types is None: | |
| relationship_types = ["*"] |
though maybe that needs an update to the type.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point, didn't know that. I think that pattern is used across the codebase. Maybe we should create a card to fix all locations
b43a2dd to
e26882f
Compare
knutwalker
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approving, waiting for whatever CI complains about :)
4a44f19 to
0cfd4ae
Compare
| assert {e for e in result["sourceNodeId"]} == {0, 1} | ||
| assert {e for e in result["targetNodeId"]} == {1, 2} | ||
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we did not depend on the neo4j ids before. As we are testing multiple version combinations on the same neo4j db, these fail here.
@soerenreichardt Instead we should get the neo-ids via a Cypher query and uses these for the expected ids
at least thats an idea
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
waiting for fix on server-side to be merged
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes that should be the reason for the flaky tests here
f89882f to
49abf48
Compare
49abf48 to
1399a3c
Compare
This got lost after a rebase
Co-Authored-By: Sören Reichardt <[email protected]>
73ff48e to
b4626fa
Compare
No description provided.