Announcement

**Isomorphic** · 22 Dec 2015, 13:48

Just to confirm: aside from these logs, are you actually seeing a problem? Note that in this case, although there seems to be an erroneous report that criteria is unchanged, a server fetch would not be expected, because the new criteria are more restrictive than the old, and the cache is complete. What would be expected is client-side filtering.

As far as how this happens - it is almost certain that what's going on is that you are getting the current criteria from the grid and modifying it in place before calling setCriteria(). Because you've already directly changed the criteria object the ResultSet is holding onto, when you pass in "new" criteria, the ResultSet detects no change.

So, can you look over your code and see if are doing something like this? If we can find the API that is directly returning the ResultSet's criteria object, we could make that API return a copy instead, to avoid issues like this one.

**Blama** · 22 Dec 2015, 14:01

Hi Isomorphic,

thanks for the fast answer. Yes, I do see a problem - the data displayed in the ListGrid does not change even though it should.
I do indeed get criteria from the grid with listGrid.getFilterEditorCriteria(true) and add additional criteria for non-visible fields to it (I get those from a RadioButton-selection).

In my example above, the filterRow-criteria is the one for LEADTEMPERATURE_ID. The additional criteria are the ones after it:

Filter LEADTEMPERATURE_ID plus OR-Crit (CREATED_BY / CREATED_BY_COMPANY_ID)
Filter LEADTEMPERATURE_ID plus CREATED_BY
Filter LEADTEMPERATURE_ID only

I build these criteria and apply them with listGrid.fetch(newCrit).

Does this information help you?

Best regards
Blama

**Isomorphic** · 22 Dec 2015, 14:31

Looking over this API, it doesn't seem like there's a way you could end up with the ResultSet's internal criteria object.

Please try the following: log the criteria you get from getFilterEditorCriteria(), and the criteria available from ResultSet.getCriteria().

Then, after you have manipulated the criteria, log the criteria returned by ResultSet.getCriteria() again, *before* calling setCriteria().

If you see that the ResultSet's criteria have been changed, then it's clear that you are somehow getting a reference to the ResultSet's internal criteria object.

The same technique can be used around any bit of code that you suspect may actually be working with the ResultSet's internal criteria object.

**Blama** · 23 Dec 2015, 05:20

Hi Isomorphic,

I tried to create a testcase, but failed to do so - it worked as expected.

Now I had a close look at my source code and made sure that in my internal methods I only return a Criterion from methods with a Criterion-signature and only AdvancedCriteria from methods with a AdvancedCriteria-signature.
I read in your answer here that one has to be careful with Object usage from Criteria / Criterion / AdvancedCriteria. Not all that is allowed in Java is valid usage.

This change (all over my code) seems to have changed something so that I now see more of the expected "setCriteria: filter criteria changed, performing local filtering"-messages.
I don't know which exact Criterion/AdvancedCriteria change fixed my application, but it seems to work now.

Nevertheless it would be great if you could add SC.logWarn()-calls to your JS (Java?) code, that will show invalid usage. Most likely this is (if disallowed) usage/return of AdvancedCriteria where Criterion is expected and usage of asAdvancedCriteria() on AdvancedCriteria objects. These two things is what I did before and removed now.

From my point of view this is closed now, as it seems to work.

Thank you & Best regards
Blama

**Isomorphic** · 23 Dec 2015, 12:38

AdvancedCriteria vs Criterion usage issues wouldn't explain this problem. What you may have done is introduced a copy operation somewhere in your refactoring that made it so that, however you obtained a copy of the internal criteria of the ResultSet, you now produce a copy somewhere in the transformation and so no longer edit it directly.

**Blama** · 24 Dec 2015, 00:29

Hi Isomorphic,

I never ask or asked the ResultSet directly for criteria.

In my ListGrid-subclass, on change of a RadioGroupItem outside the ListGrid I do now listGrid.fetchData(listGrid.getFilteredRowCriteria()).

getFilteredRowCriteria() is:

Code:

    public AdvancedCriteria getFilteredRowCriteria() {
        if (this.startAdvancedCriteria != null && this.filterCriteria != null) {
            AdvancedCriteria tmp = null;
            if (this.filterCriteria instanceof AdvancedCriteria) {
                tmp = this.filterCriteria;
            } else if (this.filterCriteria instanceof Criterion) {
                tmp = new AdvancedCriteria(this.filterCriteria);
            } else if (this.filterCriteria instanceof Criteria) {
                tmp = this.filterCriteria.asAdvancedCriteria();
            }
            tmp.addCriteria(this.startAdvancedCriteria);
            return tmp;
        } else if (this.startAdvancedCriteria != null) {
            return this.startAdvancedCriteria;
        } else if (this.filterCriteria != null) {
            return this.filterCriteria;
        } else {
            return null;
        }
    }

It was before:

Code:

    private void setFilteredRowCriteria() {
        if (startCriteria != null && filterCriteria != null) {
            // TODO Test ST: Test with new object
            filteredRowCriteria = new AdvancedCriteria(filterCriteria);
            filteredRowCriteria.addCriteria(startCriteria);
        } else if (startCriteria != null) {
            filteredRowCriteria = startCriteria;
        } else {
            filteredRowCriteria = filterCriteria;
        }
    }

    public AdvancedCriteria getFilteredRowCriteria() {
        return filteredRowCriteria;
    }

These are the class variables (now without filteredRowCriteria):

Code:

    protected AdvancedCriteria startCriteria = null;
    protected AdvancedCriteria filterCriteria = null;
    protected AdvancedCriteria filteredRowCriteria = null;

Use case is the following: I persist the filterRow Criteria with a FilterEditorSubmitHandler.
On start, I apply these and the criteria I get from the mentioned RadioGroupItem to the ListGrid. On change of the RadioGroupItem I get the current listGrid.getFilterEditorCriteria(true) and again add the RadioGroupItem-criteria.

Does the old version somehow look suspicious to you? I'd really like to understand what is/was happening, even though it seems to work now.

Thank you & Best regards
Blama

**Isomorphic** · 24 Dec 2015, 00:40

No need to speculate - post 4 above gives you the definitive way to see if have somehow ended up with a reference to the ResultSet's internal criteria.

**Blama** · 24 Dec 2015, 02:35

Hello Isomorphic,

I did that. My change handler for the RadioGroupItem has:

Code:

        public void onChanged(ChangedEvent event) {
            String selectedLeadTypeOption = event.getValue().toString();
            LeadlistManagement listGrid = leadVLayout.getListGrid(sectionName);

            if (listGrid != null) {
                    [B]SC.logWarn("ResultSet Criteria BEFORE: " + listGrid.getOriginalResultSet().getCriteria().asAdvancedCriteria().asString());[/B]
                // update the start Criteria.
                if (getCriterion(selectedLeadTypeOption) != null) {
                    listGrid.setStartCriteria(getCriterion(selectedLeadTypeOption).asAdvancedCriteria());
                } else {
                    listGrid.setStartCriteria(null);
                }
                // update the filter Criteria. [B]In the testcase, where I have the problem always not null[/B]
                if (listGrid.getFilterEditorCriteria(true) != null && !listGrid.getFilterEditorCriteria(true).getValues().isEmpty()) {
                    listGrid.setFilterCriteria(listGrid.getFilterEditorCriteria(true).asAdvancedCriteria());
                    [B]SC.logWarn("ResultSet Criteria AFTER: " + listGrid.getOriginalResultSet().getCriteria().asAdvancedCriteria().asString());[/B]
                    listGrid.setShowFilterEditor(true);
                } else {
                    listGrid.setShowFilterEditor(false);
                }
                listGrid.fetchData(listGrid.getFilteredRowCriteria());
            }
        }

I can see that in the case where the RadioGroupItem changeHandler returns null, the result is different to when it does not. This is also the RadioGroupItem-change that triggered the error.
In the good case, the log shows the old criteria for both SC.logWarn(), in the bad case, it shows the new criteria for the 2nd SC.logWarn().

The code there for my own method setFilterCriteria() is:

Code:

    public void setFilterCriteria(AdvancedCriteria filterCriteria) {
        this.filterCriteria = filterCriteria;
        setFilteredRowCriteria();
    }

    // the filteredRowCriteria is startCriteria if filterCriteria == null
    private void setFilteredRowCriteria() {
        if (startCriteria != null && filterCriteria != null) {
            filteredRowCriteria = new AdvancedCriteria(filterCriteria);
            filteredRowCriteria.addCriteria(startCriteria);
        } else if (startCriteria != null) {
            filteredRowCriteria = startCriteria;
        } else {
            [B]filteredRowCriteria = filterCriteria;[/B]
        }
    }

The bold line is the one I suspect as causing the bug. filteredRowCriteria is later on used in listGrid.fetchData(listGrid.getFilteredRowCriteria()) (see post 7).

Do I have to return a new object here? E.g.

filteredRowCriteria = new AdvancedCriteria(filterCriteria);

? I tried that, but that does not make the 1st and 2nd log to report the same old value.

Best regards
Blama

**Isomorphic** · 28 Dec 2015, 18:18

If you are ending up modifying the internal criteria, you would need a deep copy (recurring into nested criteria) to aboid the problem.

But unfortunately, with a close analogue of your code, we can't see an issue where application code is able to get a reference to the internal criteria object.

We realize you already have a working solution, but if you find time to create a test we can run, we'd certainly like to get to the bottom of this, and create the framework bug if there is indeed one (or clarify usage further if not).

Announcement

Serious bug with 5.1p ResultSet Criteria-change detection

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment