-
Notifications
You must be signed in to change notification settings - Fork 60
Distinct History Object for nodes and edges #2075
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
Draft
arienandalibi
wants to merge
21
commits into
master
Choose a base branch
from
feature/history-object
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…HistoryObject holds iterators over history items to return them as needed. HistoryObjects can be aggregated in CompositeHistory.
…yObject is now a trait. HistoryImplemented holds a node or edge object and retrieves forward and reverse iterators through functions. CompositeHistory now holds a vector of Boxes containing HistoryObjects.
…hey return MergedHistory and CompositeHistory wrapped in HistoryImplemented objects respectively. MergedHistory holds two InternalHistoryOps objects while CompositeHistory stores a vector of arbitrarily many. MergedHistory is slightly more efficient but if nested with itself, can lose efficiency.
…o3 file doesn't compile yet
…t an iterator over the history events in the history object. History objects can be created from nodes and edges. We can do list(history_object) in python. Removed Arc constraint on the history object.
…ors. Attempted to implement __eq__ and __ne__ for python objects. Added timeindex.rs file to raphtory-api module to support the conversion of TimeIndexEntry type into PyRaphtoryTime, accessible in python.
… functions still need to be added
…Started work on python compose_from_items() function, doesn't work yet. Can't retrieve the python objects. Implemented first iteration of graphql file
…m in graphql. Implemented hashing both in rust and in python. They can theoretically now be used in hashmaps (maps) in python.
…directly on nodes and edges, using windows, using layers, and using property filters.
…nd manipulated. They implement Eq and Ord functionalities, even in python
…er than a vec<i64>
…object is called History. Fixed implementation of NodeOp for HistoryOp.
…turned as a result of applying HistoryOp
…TemporalPropertyView and ran rustfmt
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What changes were proposed in this pull request?
The history object will take care of the history of nodes and edges. It will also implement different functionalities so they don't have to be implemented in Python by the user.
Why are the changes needed?
Improve user experience when dealing with histories by implementing useful features out of the box.
Does this PR introduce any user-facing change? If yes is this documented?
The history object itself, which will be documented
How was this patch tested?
Not been tested yet
Are there any further changes required?
Integration with Raphtory