How to select all items in a grid? I see there is a method grid.deselectAll() but there is no selectAll(). I’ve custom filter based on which I need to selectAll items.
setSelectionMode returns an object where you can call select all.
I did this GridSelectionModel<PropertyBox> gridSelectionModel = grid.setSelectionMode(Grid.SelectionMode.MULTI); But still there is no selectAll method from object gridSelectionModel. Any other class to try ?
You have to cast it to the multi select model
Yes, this one GridMultiSelectionModel gridMultiSelectionModel = (GridMultiSelectionModel) grid.setSelectionMode(Grid.SelectionMode.MULTI); has the selectAll method. But this selectAll() is not making the items checkboxes selected. They’re still showing as unselected.
I’m still missing something ?
1 Like
Might be a bug - looking at the select all checkbox at the top, it is correctly selected. You could open an issue in the flow-components repo. But it should only be a visible bug, the selection should work for further processing
Make sure your Bean classes implement hashCode and equals correctly: The Grid and the problem of broken equals()/hashCode() – Martin Vysny – First Principles Thinking
I was using some third party library which was not recognizing the version column and so not working as expected. After removing I see the checkbox is selecting all but still there is one issue. The number of items selected is one but the sql query count says 2147483647
select
c1_0.id,
c1_0.company_name,
c1_0.contact_name,
c1_0.created_by,
c1_0.created_date,
c1_0.customer_segment,
c1_0.customer_since,
c1_0.customer_type,
c1_0.industry_type,
c1_0.last_modified_by,
c1_0.last_modified_date,
c1_0.lead_source,
c1_0.notes,
c1_0.version
from
customers c1_0
order by
c1_0.company_name
limit
0,2147483647
What could be the issue?
Grid tracks all individual selected items in memory so that e.g. getSelectedItems() can work as expected. In other words, it doesn’t handle selection based on a range or an “all selected” flag because those might lead to surprises if a user performs an action on all selected items and that would include newly created items that are not visible in the user’s Grid.
This means that when you select all items, Grid needs to fetch all of them from the database. Since the DataProvider interface is based on fetching a specific range of items, Grid sends a request for items between 0 and Integer.MAX_VALUE to make sure it finds them all.
When I’m creating a grid with just one ComponentColumn how does it know the equals/hashCode to use ? The problem is, I see two queries are getting executed
1731838764792|4ms|statement|connection 1|select i1_0.id,i1_0.item_name,i1_0.sku from item i1_0 where lower(i1_0.item_name) like ? escape '!' limit ?,?|
HeFormatSql(P6Spy sql,Hibernate format):
select
i1_0.id,
i1_0.item_name,
i1_0.sku
from
item i1_0
where
lower(i1_0.item_name) like '%%' escape '!'
limit
0, 2147483647
1731838764858|1ms|statement|connection 2|select i1_0.id,i1_0.item_name,i1_0.sku from item i1_0 where lower(i1_0.item_name) like ? escape '!' limit ?,?|
HeFormatSql(P6Spy sql,Hibernate format):
select
i1_0.id,
i1_0.item_name,
i1_0.sku
from
item i1_0
where
lower(i1_0.item_name) like '%%' escape '!'
limit
0, 50
```.This is the equals/hashCode I’ve
@Override
public boolean equals(Object o) {
if (this == o) return true;
if (o == null || getClass() != o.getClass()) return false;
Item item = (Item) o;
return Objects.equals(id, item.id);
}
@Override
public int hashCode() {
return Objects.hash(id);
}
But still it is executing two statements
It always uses the equals and hashCode method of the item type which I guess is PropertyBox based on your previous code example. The value or component of any specific column is never used for comparing selections.
I would recommend putting a breakpoint in your data provider callback to get clues about why it’s called with specific parameters. I would guess that the 0, 2147483647 query is to load all items into the selected field in AbstractGridMultiSelectionModel and then the 0, 50 query is to refresh the currently visible items. It is true that the second query is in one way redundant but I guess it would be tricky to avoid it due to the way the 0, 2147483647 is a special case that happens from a different part of the implementation.