Skip to content
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

[VP7iRcuF] Introduce helper methods from neo4j #187

Merged
merged 9 commits into from
Oct 5, 2022

Conversation

Lojjs
Copy link
Contributor

@Lojjs Lojjs commented Sep 16, 2022

In order to decrease the dependencies of internal Neo4j APIs, it was decided to copy over some of the helper classes into APOC.

Proposed Changes (Mandatory)

A brief list of proposed changes in order to fix the issue:

  • Copy over all relevant parts of the org.neo4j.internal.helper.collection package from Neo4j
  • Remove benchmarking code which is old and unused

Notes for the reviewer

  • Some of the helper files which have been copied over from Neo4j also had accompanying test classes. Do we want to move over relevant parts of these as well?
  • This will break APOC extended, as several places there call public core methods which have now changed signature from e.g. org.neo4j.internal.helpers.collection.Pair to apoc.util.collection.Pair. Should we make a Trello card for fixing this?

Copy link
Collaborator

@vga91 vga91 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A really good job :), I just added some small (mostly subjective) things I think could be changed

}

public static <FROM, TO> Iterable<TO> map(Function<? super FROM, ? extends TO> function, Iterable<FROM> from) {
return new MapIterable<>(from, function);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since all Iterables.map(..) is always used in together with Iterables.asList(..), maybe it might be worth using the stream API, writing e.g. Iterables.stream(node.getRelationshipTypes()).map(RelationshipType::name).collect (Collectors.toList()); instead of Iterables.asList(Iterables.map(RelationshipType::name, node.getRelationshipTypes())); [line 576 of apoc.nodes.Nodes.java].

This way, we can remove both this method and the MapIterable class.

* @param <T1> the type of the {@link #first() first value} of the pair.
* @param <T2> the type of the {@link #other() other value} of the pair.
*/
public abstract class Pair<T1, T2> {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we could use org.apache.commons.lang3.tuple.Pair instead of this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm I guess we could, as we already depend on org.apache.commons.lang3

@@ -34,7 +34,7 @@ public void add( Node node )
void addNode( long id, Node data )
{
nodes.put( id, data );
labels.addAll( Iterables.asCollection( data.getLabels() ) );
labels.addAll( Iterables.addAll( new ArrayList<>(), data.getLabels() ) );
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
labels.addAll( Iterables.addAll( new ArrayList<>(), data.getLabels() ) );
Iterables.asList(data.getLabels())

@@ -1,7 +1,6 @@
package apoc.convert;

import org.neo4j.internal.helpers.collection.Iterators;

import apoc.util.collection.Iterators;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not directly related, but we could change rows 20 and 21 with these?

        else if (list instanceof Iterable) return Iterables.asList((Iterable)list);
        else if (list instanceof Iterator) return Iterators.asList((Iterator)list);

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice catch!

* @param iterator the iterator to expose as an {@link Iterable}.
* @return the supplied iterator posing as an {@link Iterable}.
*/
public static <T> Iterable<T> loop(final Iterator<T> iterator) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we could also use Iterator.forEachRemaining instead of this?

@vga91
Copy link
Collaborator

vga91 commented Sep 26, 2022

  • Some of the helper files which have been copied over from Neo4j also had accompanying test classes. Do we want to move over relevant parts of these as well?
  • This will break APOC extended, as several places there call public core methods which have now changed signature from e.g. org.neo4j.internal.helpers.collection.Pair to apoc.util.collection.Pair. Should we make a Trello card for fixing this?

For me yes, both, I think it is worth adding some tests and the APOC extended trello card

@Lojjs Lojjs force-pushed the dev-introduce-helper-methods-from-neo4j branch 3 times, most recently from ed358d8 to d2b7c42 Compare September 30, 2022 10:06
@Lojjs Lojjs changed the title Introduce helper methods from neo4j [VP7iRcuF] Introduce helper methods from neo4j Oct 3, 2022
Lojjs added 8 commits October 4, 2022 08:47
To reduce dependencies of internal APIs
To reduce dependencies of internal Neo4j APIs
This benchmarking code which used internal Neo4j APIs is unused and related to auto-indexing which does not exist in Neo4j anymore.
@Lojjs Lojjs force-pushed the dev-introduce-helper-methods-from-neo4j branch from d2b7c42 to 61ef528 Compare October 4, 2022 06:57
Copy link
Collaborator

@vga91 vga91 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd just change one more thing (optional). Except this one LGTM :)


// Then
assertThat( Iterators.asList(iterator)).containsExactlyElementsOf(items);
assertThat(iteratorClosed.isTrue()).isTrue();
Copy link
Collaborator

@vga91 vga91 Oct 4, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems a bit repetitive, at least for me. Maybe I would write:

Suggested change
assertThat(iteratorClosed.isTrue()).isTrue();
assertTrue(iteratorClosed.booleanValue());

or

Suggested change
assertThat(iteratorClosed.isTrue()).isTrue();
assertTrue(iteratorClosed.getValue());

Same thing for other similar ones (lines 55, 86, 114-117, 167, 194-196, 232-234, 264-266, 295, 296, 318).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I ended up doing the first suggestion and applied it for the other test files as well

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants