Eclipse Community Forums: NatTable » GroupBy example has row count problems

Help

Home

Home » Eclipse Projects » NatTable » GroupBy example has row count problems

Show: Today's Messages :: Show Polls :: Message Navigator

GroupBy example has row count problems [message #1064929]

Fri, 21 June 2013 17:11

Patrick Rusk

Messages: 35
Registered: June 2012

Member

I've been integrating the GroupBy functionality into our application and only just now noticed a row counting problem.

If you try the "Column and row grouping/Group by" example, you will note that it has 200 rows when there is no grouping. Now, group on any row. It still has 200 rows, with no added rows for the new tree node rows.

I'll be looking into this further and filing a bug report when I can characterize the problem a bit better. But, meanwhile, is this generally known? Has there been any discussion about it. I couldn't find any.

Thanks.

Report message to a moderator

Re: GroupBy example has row count problems [message #1064936 is a reply to message #1064929]

Fri, 21 June 2013 17:35

Patrick Rusk

Messages: 35
Registered: June 2012

Member

Here's a bit more information...

When I group on "Rating", there are 200 rows. There should be 210 rows.

Now, if I collapse the first node and then expand it, there are 210 rows.

If I then ungroup on "Rating" and scroll to the bottom, it is still attempting to show 210 rows, but the last 10 are having exceptions.

I will hazard a guess that the act of grouping/ungrouping is not firing the proper RowStructureEvent for the table. Trying that now...

Report message to a moderator

Re: GroupBy example has row count problems [message #1064946 is a reply to message #1064936]

Fri, 21 June 2013 19:23

Patrick Rusk

Messages: 35
Registered: June 2012

Member

Phew! It looks like this is resolved by modifying GroupByDataLayer.update() to read:

	@Override
	public void update(Observable o, Object arg) {
		updateTree();
		fireLayerEvent(new RowStructuralRefreshEvent(this)); // <== new line
	}

I'll submit a bug for this.

Report message to a moderator

Re: GroupBy example has row count problems [message #1064948 is a reply to message #1064946]

Fri, 21 June 2013 19:46

Dirk Fauth

Messages: 2815
Registered: July 2012

Senior Member

I'm not sitting in front of the code right now. But that event should be fired by the GlazedListsEventLayer and should not be needed to be fired manually in the GroupByDataLayer.

Report message to a moderator

Re: GroupBy example has row count problems [message #1064952 is a reply to message #1064948]

Fri, 21 June 2013 21:11

Patrick Rusk

Messages: 35
Registered: June 2012

Member

I don't doubt that you are right. However, GlazedListsEventLayer isn't involved at all in the "Group by" example.

In my own code, derived from early NatTableBuilder code, the GlazedListsEventLayer wraps the GroupByDataLayer. That suggests to me that GroupByDataLayer needs to do something more dramatic in its update() method to inform GlazedListsEventLayer that it needs to send out an event. Perhaps the odd code in updateTree() is meant to do that, but it doesn't seem sufficient, perhaps because it doesn't change the number of elements in the underlying event list.

Report message to a moderator

Re: GroupBy example has row count problems [message #1064966 is a reply to message #1064952]

Sat, 22 June 2013 06:31

Dirk Fauth

Messages: 2815
Registered: July 2012

Senior Member

I will investigate in this after I'm done with another issue.

Report message to a moderator

Re: GroupBy example has row count problems [message #1065108 is a reply to message #1064966]

Mon, 24 June 2013 11:44

Dirk Fauth

Messages: 2815
Registered: July 2012

Senior Member

Hi Patrick,

so I investigated in this issue, and you are on the right spot as it seems. Even if the GlazedListsEventLayer is added to the layer stack, there is no correct update of the list elements.

The issue is that
- on performing the update of the tree dependent on the grouping, only UPDATE events are fired by the TreeList
- the GlazedListsEventLayer only handles DELETE and INSERT events as structural changes, for UPDATE there is only a VisualRefreshEvent fired
- the GroupByColumnCommandHandler and the UngroupByColumnCommandHandler are registered against the GroupByHeaderLayer, which means the underlying layers are not informed about changes. Also the commands are also just firing VisualRefreshEvents. They should be RowStructuralChangeEvents.

The solution to simply fire the RowStructuralChangeEvent in the update() method as you suggested would be one valid way to go. Another way would be to move the special command handlers to the GroupByDataLayer and let them fire RowStructuralChangeEvents.

After my investigation I would go with your solution, as the events are usually designed to be fired by the layers rather than the commands. But before I'm modifying things I would like to hear Edwins opinion on this. So could you please open a new ticket and link to this topic? Then I will add my investigation results and my opinion into the ticket, so Edwin is possible to get involved.

Thanks for your testing and investigation efforts on this!

Greez,
Dirk

Report message to a moderator