Fix getChildCount to always use filter, filtering based on flatten hierarchy of children

[Klaudeta]

Fixes vaadin-grid-flow/issues/464

---

This change is 

[CLAassistant]

All committers have signed the CLA.

[CLAassistant]

Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[ujoni]

I am a little conflicted about these changes - I didn't fully understand the original issue, but the Javadoc in HierarchicalDataProvider<T, F> reads

    /**
     * Get the number of immediate child data items for the parent item returned
     * by a given query.
     *
     * @param query
     *            given query to request the count for
     * @return the count of child data items for the data item
     *         {@link HierarchicalQuery#getParent()}
     */
    public int getChildCount(HierarchicalQuery<T, F> query);

since the new code both flattens and filters the whole sub-hierarchy for the getParent() (right?), the Javadoc is very wrong, as it claims it does neither of those things.

Should we try to adhere to the Javadoc, or just update it?

-> I am not familiar with the original intentions regarding these files :<

Reviewable status: all discussions resolved, 0 of 1 LGTMs obtained (waiting on @ZheSun88)

[Klaudeta]

getChildCount is supposed to return the total number of children that should be returned from fetchChildren. Because this was not happening (the filtering was not taken into account inside the getChildCount) then the HierarchicalDataCommunicator was doing a wrong calculation of items to be send to the client resulting in an IndexOutOfBoundsException exception. The change done is still respecting what the javadoc says. It is up to the implementation of that interface to take care of how the method is being implemented. In case of TreeDataProvider extending HierarchicalDataProvider, if a filter is available then getChildCount and fetchChildren should take into account that filter (both of them).

getChildCount is still returning the total number of child items after they go through the filter. The filter itself should not check if the that child satisfy the filter but should check if any of the upcoming children and grandchildren (and so on) satisfy the filter and this is where the flatten of the hierarchy is used.

Reviewable status: all discussions resolved, 0 of 1 LGTMs obtained (waiting on @ZheSun88)

[ujoni]

Yeah. Seems like I somehow had misread

stream = stream.filter(parent -> flatten(parent).anyMatch(filter));

and just taken it in as a simple filter over the flattened hierarchy. How? Who knows.

Reviewed 1 of 1 files at r1.
Reviewable status: all discussions resolved, 0 of 1 LGTMs obtained (waiting on @ZheSun88)

[ujoni]

Reviewable status: complete! all discussions resolved, 1 of 1 LGTMs obtained (waiting on @ZheSun88)

[ZheSun88]

The build failed on TreeDataProviderTest.addFilter and TreeDataProviderTest.setFilter tests

Reviewable status: complete! all discussions resolved, 1 of 1 LGTMs obtained (waiting on @ZheSun88)

[Klaudeta]

Reviewable status: 1 unresolved discussion, 0 of 1 LGTMs obtained, and 1 stale (waiting on @ujoni and @vaadin-bot)

---

flow-data/src/main/java/com/vaadin/flow/data/provider/hierarchy/TreeDataProvider.java, line 19 at r2 (raw file):

Previously, vaadin-bot (Vaadin Bot) wrote…

Remove this unused import 'java.util.List'.

Done.

[ujoni]

Reviewed 1 of 1 files at r3.
Reviewable status: 1 unresolved discussion, 1 of 1 LGTMs obtained (waiting on @vaadin-bot)