Fixes #1464: Create apoc.temporal.overlap(start1, end1, start2, end2, acceptAdjacentSpans:true) function #3994
Conversation
This file contains 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
… acceptAdjacentSpans:true) function
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.
Fixes #1464
Created
apoc.temporal.overlapfunction.TO EVALUATE: It also refers to temporal spans, but perhaps it is worth considering all possible data types, for example to compare two ranges of longs (e.g.
with 1 as start1, 4 as end1, 3 as start2, 4 as end2 return (start1 < end2) AND (start2 < end1) AS value).In that case, we could rename the procedure as
apoc.util.overlap.TO EVALUATE: Consistently with Cypher, if the data types are not comparable (see testOverlapWithWrongTypes), the procedure returns
null.Alternatively, we could return for example a
RuntimeException("type not comparable..."),or perhaps we can add another config
failSilently: <boolean>that returns null if the config true.The issue suggests using
max(start1, start2) <= min(end1, end2), but for simplicity, I think it is better to use the other formula suggested in stackoverflow, that is(Start1 <= End2) and (Start2 <= End1).The procedure leverages
tx.execute(<query>)instead of using the Java API, e.g. the AnyValues.COMPARATOR, since this way we are sure that the behavior is consistent with Cypher.