PostgreSQL: Fix views\Tests\Handler\FieldFieldTest

Do you mind posting the result output, maybe for example the which is failing? Its a bit non trivial to follow what went wrong.

We have a few similar assertions in that test, and the previous ones use $this->assertEqual(0, ...); instead of the current assertIdentical().

I can not reproduce the test fail on my local install with SQLite, but the patch attached fixes Posgres. Let's try a mysql testbot run :)

Here's an example of the same assertion that already exists in that test: http://cgit.drupalcode.org/drupal/tree/core/modules/views/src/Tests/Hand...

So the rendered result changes on a different database? WOW
It seems to be for me that this is though not the absolute right fix, why, views has a feature to hide a field in case its empty (or optionally also 0).
Is there really no way to ensure that both databases have a similar behaviour ?

Good question, I was wondering this as well.

I can only think of doing a COALESCE as an alternative, but that seems to me to be even more weird.

I think this is happening somewhere between entity/field loading as this view, per @dawehner, is fetching the id and loading entities to compare against.

I'm changing to Needs Work based on #4, #5, and #6.

Yes, I also think that using COALESCE would be the solution to fix Views' queries, but this issue is just about fixing a test fail introduced in Postgres and SQLite by #1867518: Leverage entityDisplay to provide fast rendering for fields.

Like I said in #2, the patch is just changing an assertion to match all the others from the same test file, and it fixes the test on Postgres and SQLite so can we please discuss improving Views in a different issue? :)

Like I said in #2, the patch is just changing an assertion to match all the others from the same test file, and it fixes the test on Postgres and SQLite so can we please discuss improving Views in a different issue? :)

As @mradcliffe said, this is a really odd behaviour, I think we should fix the actual problem and not just the test. There is no reason that you expect "0" to be rendered in that case,
so you effectively bypass a bug here.

The bug was there before #1867518: Leverage entityDisplay to provide fast rendering for fields (and it most likely exists in Views 7.x as well) and *a lot* of assertions from this test class are already bypassing it, see an identical one here: http://cgit.drupalcode.org/drupal/tree/core/modules/views/src/Tests/Hand...

I really don't understand why we would want to block this issue on refactoring Views queries. If we had SQLite and Postgres testing, #1867518: Leverage entityDisplay to provide fast rendering for fields wouldn't have introduced the failing test in the first place, and this is just a small followup to cleanup after that patch...

So I don't think we should block this patch on the views fix - because once we get to 100% pass on sqlite and/or postgres, it's going to be much easier to spot other regressions introduced elsewhere, that's more important than the rendering discrepancy.

However we do need an at-least-major issue for the rendering discrepancy and we should document here that the test is working around that.

Opened the major follow-up and linked it in the test code. #2488006: Views' Field handler returns different output depending on the database driver

Fair deal!

I've run the test on postgres, mysql, and sqlite and it passes - nice. Committed 47f69d8 and pushed to 8.0.x. Thanks!