-
Notifications
You must be signed in to change notification settings - Fork 64
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
54
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
+4,329
−622
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
# Conflicts: # raphtory-graphql/src/model/graph/edge.rs # raphtory-graphql/src/model/graph/mod.rs # raphtory-graphql/src/model/graph/node.rs
…return TimeIndexEntry instead of i64. Created new EarliestDateTime struct which implements NodeOp but returns DateTime<Utc> instead of i64, might be removed later. Removed NodeOpFilter from Map for NodeOp
…s. Currently supports OutOfRange when trying to convert to DateTime<Utc> from an out-of-range i64 and NotFound for operations where a time entry is not found. Changed output type of dt() from an Option to a Result so that these errors can be propagated.
… Options for time information which isn't found, now Result<Option<DateTime>, GraphError>. Continued integrating these in the python interface. Errors in macros persist.
…urn my history object. Changed function temporal_history() of TemporalPropertyViewOps to return TimeIndexEntries instead of i64. Propagated changes
…eed to handle Results differently. We might need a new Op type that can return errors so they can be handled properly, especially in the macros.
…ect. Merged 'time semantics overhaul'. # Conflicts: # pometry-storage-private # raphtory-api/src/python/mod.rs # raphtory/src/db/api/properties/internal.rs # raphtory/src/db/api/properties/temporal_props.rs # raphtory/src/db/api/state/ops/history.rs # raphtory/src/db/api/storage/graph/storage_ops/time_props.rs # raphtory/src/db/api/storage/graph/storage_ops/time_semantics.rs # raphtory/src/db/api/view/edge.rs # raphtory/src/db/api/view/graph.rs # raphtory/src/db/api/view/internal/time_semantics.rs # raphtory/src/db/api/view/node.rs # raphtory/src/db/api/view/time.rs # raphtory/src/db/graph/edge.rs # raphtory/src/db/graph/node.rs # raphtory/src/db/graph/views/deletion_graph.rs # raphtory/src/db/graph/views/window_graph.rs # raphtory/src/errors.rs # raphtory/src/python/graph/node.rs # raphtory/src/python/packages/base_modules.rs # raphtory/src/python/types/repr.rs
…ect. Merged 'time semantics overhaul'. # Conflicts: # pometry-storage-private # raphtory-api/src/python/mod.rs # raphtory/src/db/api/properties/internal.rs # raphtory/src/db/api/properties/temporal_props.rs # raphtory/src/db/api/state/ops/history.rs # raphtory/src/db/api/storage/graph/storage_ops/time_props.rs # raphtory/src/db/api/storage/graph/storage_ops/time_semantics.rs # raphtory/src/db/api/view/edge.rs # raphtory/src/db/api/view/graph.rs # raphtory/src/db/api/view/internal/time_semantics.rs # raphtory/src/db/api/view/node.rs # raphtory/src/db/api/view/time.rs # raphtory/src/db/graph/edge.rs # raphtory/src/db/graph/node.rs # raphtory/src/db/graph/views/deletion_graph.rs # raphtory/src/db/graph/views/window_graph.rs # raphtory/src/errors.rs # raphtory/src/python/graph/node.rs # raphtory/src/python/packages/base_modules.rs # raphtory/src/python/types/repr.rs
…t conversion could fail
…ture/history-object # Conflicts: # raphtory-api/src/python/mod.rs # raphtory/src/db/api/properties/internal.rs # raphtory/src/db/api/properties/temporal_props.rs # raphtory/src/db/api/state/ops/history.rs # raphtory/src/db/api/storage/graph/storage_ops/time_props.rs # raphtory/src/db/api/view/edge.rs # raphtory/src/db/api/view/graph.rs # raphtory/src/db/api/view/node.rs # raphtory/src/db/api/view/time.rs # raphtory/src/db/graph/views/deletion_graph.rs # raphtory/src/python/graph/node.rs # raphtory/src/python/packages/base_modules.rs # raphtory/src/python/types/repr.rs
…r node_view and edge_view. iter_rev does not apply TimeSemantics filtering for edge_view yet.
…istoryOp on nodes now has a lifetime because NodeView has a lifetime and is contained in the output History Object.
52253c7
to
c0d3801
Compare
…ject as comments in case we want to use them instead. Fixed tests because they were failing after the refactor
…time, ...) to return TimeIndexEntry for nodes, edges, and temporal props. Propagated these TimeIndexEntries.
…in reverse, both for edge_history and edge_history_window functions. Updated history object to use these new functions
eacf1f4
to
f2d003b
Compare
…in reverse, both for node_history and node_history_window functions. Updated history object to use these new functions
…them to fix lifetime issues. Fixed many errors in Python module. Propagated TimeIndexEntries in many functions, especially relating to props. Added equality comparison on History object and on TimeIndexEntry==i64.
…f holding a vector of interval values. The interval values can be calculated lazily.
…tries instead of owning the item. Updated tests for intervals and for the history object when using a layer.
…ad of a vector of all timestamps
…istory object whose iter() and collect() functions yield items of the appropriate type (i64 timestamp, DateTime<Utc>, or secondary index). They all own the InternalHistoryOps object they use (by receiving a clone), same in intervals and merge. That is, except in HistoryRef, where they receive a reference. Added len function to InternalHistoryOps. Clone requirement added throughout History.rs.
b6b163f
to
1a4bd39
Compare
…. Fixed some History earliest_time and latest_time implementations in aggregate types to call respective inner time functions. CompositeHistory is now generic over lifetimes (namely NodeViews with 'graph lifetime).
…64. History object's earliest_time and latest_time can now be done more efficiently by calling the edge's appropriate functions. History objects are now generic over lifetimes
…. They map each node to a History object containing it. Wrote test cases for graph.nodes().history(), which returns a history object per node, and for History::new(LazyNodeState<HistoryOp...>), which returns a single history object for all nodes. The latter orders all time entries for the whole set of nodes, while the former only orders time entries within each node.
…raph.node("some_node").neighbours().combined_history() by implementing InternalHistoryOps for PathFromNode and PathFromGraph.
…on. Created some new types for Python iterables, especially for edges. Started working on macros for node ops as well. Still unfinished.
…ges functions in Python. PyGenericIterator and PyNestedGenericIterator have "from_result_iter" and "from_nested_result_iter" constructors to support result types.
…t. Added HistoryTimestamp, HistoryDateTime, and HistorySecondary in Python. Fixed PyPathFromGraph iterable return types. Fixed errors
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