[hibernate-dev] When is Dialect.requiresCastingOfParametersInSelectClause applied?

[Vlad Mihalcea]

Hi,

If there is just one test case that doesn't work for a specific Dialect
because the Dialect does not support such feature,
you can just skip it for that Dialect either directly or through a
DialectChecks.

One example: when a test uses sequences, you need to use a DialectCheck
because otherwise it will fail on MySQL.

Vlad

On Mon, Jan 30, 2017 at 7:00 PM, Mark Rotteveel <mark at lawinegevaar.nl>
wrote:

> After a hiatus of 6 months, I have gone back to my PR for
> improving/replacing the Firebird dialect. I am running into a number of
> test failures which I am working through to see if they are relevant or
> not.
>
> One of the test failures I am looking at is
> org.hibernate.jpa.test.criteria.basic.ConcatTest.testSelectCaseWithConcat
>
> Firebird is rather picky about parameters occurring in the
> select-clause, and they will almost always need to be cast to the
> necessary type (and lengths). This tests seems to generate the following
> query:
>
>      select
>          case
>              when concattest0_.id is not null then (?||?)
>              else 'Empty'
>          end as col_0_0_,
>          trim(both ' '
>      from
>          (?||?)) as col_1_0_
>      from
>          TEST_ENTITY concattest0_
>
> I have implemented Dialect#requiresCastingOfParametersInSelectClause()
> to return true, but unfortunately for this specific test it has no effect.
>
> The absolute minimum SQL necessary for this to work (with some caveats) is:
>
>      select
>          case
>              when 1 = 1 then (?||?)
>              else 'Empty'
>          end as col_0_0_,
>          trim(both ' '
>      from
>          (cast(? as varchar(256))|| cast(? as varchar(256)))) as col_1_0_
>      from
>          TEST_ENTITY concattest0_
>
> And preferably the (?||?) in the case should have an explicit cast for
> each parameter as well, as otherwise each parameter is limited to 5
> characters each (setting longer values will lead to a truncation
> exception).
>
> Is this something that is fixable, and if so how? Or is this one of
> those things where you just have to say 'aw, too bad, let it go' (or,
> maybe: do it later if it is really necessary)?
>
> With this specific failure out of the way: what is the general rule of
> thumb of handling test failures in hibernate_core for a lesser-known
> dialect?
>
> I currently have 257 test failures (and 512 ignored) with Firebird and
> my new dialect. I might add that some failures seem to be generic (eg
> DriverManagerRegistrationTest, StandardRefCursorSupportTest,
> NoCdiAvailableTest, XmlAccessTest, FetchProfileTest, IndexTest and some
> others).
> --
> Mark Rotteveel
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>