Re: [hibernate-dev] Form-feed (\f 0x0C) in generated SQL
by Mark Rotteveel
Thanks!
I just received a build failure notification with an ExceptionInInitialiserError, but I can't see how my PR would introduce that error.
Any idea, or should I just ignore it?
Mark
----- Bericht beantwoorden -----
Van: "Sanne Grinovero" <sanne(a)hibernate.org>
Aan: "Mark Rotteveel" <mark(a)lawinegevaar.nl>
CC: "Hibernate.org" <hibernate-dev(a)lists.jboss.org>
Onderwerp: [hibernate-dev] Form-feed (\f 0x0C) in generated SQL
Datum: di, feb. 7, 2017 18:08
merged it, and promoted your JIRA account so you can assign issues to yourself.
Thanks!
Sanne
On 7 February 2017 at 15:58, Mark Rotteveel <mark(a)lawinegevaar.nl> wrote:
> Issue: https://hibernate.atlassian.net/browse/HHH-11467
> PR: https://github.com/hibernate/hibernate-orm/pull/1781
>
> On 4-2-2017 15:05, Mark Rotteveel wrote:
>> Firebird has a problem with some of the SQL generated by Hibernate, in
>> some queries Hibernate appends StringHelper.WHITESPACE between
>> conditions (specifically in CollectionBinder.bindFilters(boolean)).
>>
>> The problem is that StringHelper.WHITESPACE contains a formfeed (\f,
>> 0x0C), and Firebird does not accept a formfeed as whitespace.
>>
>> It looks like the usage of StringHelper.WHITESPACE is wrong; the other
>> places this constant is used is for splitting/tokenizing strings, and
>> not for adding whitespace.
>>
>> Is there any objection if I replace the usage in
>> CollectionBinder.bindFilters(boolean) with a single space (or maybe with
>> " \n\t" to produce more similar SQL as previous)?
>>
>> Mark
>>
>
>
> --
> Mark Rotteveel
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
6 years, 1 month
Form-feed (\f 0x0C) in generated SQL
by Mark Rotteveel
Firebird has a problem with some of the SQL generated by Hibernate, in
some queries Hibernate appends StringHelper.WHITESPACE between
conditions (specifically in CollectionBinder.bindFilters(boolean)).
The problem is that StringHelper.WHITESPACE contains a formfeed (\f,
0x0C), and Firebird does not accept a formfeed as whitespace.
It looks like the usage of StringHelper.WHITESPACE is wrong; the other
places this constant is used is for splitting/tokenizing strings, and
not for adding whitespace.
Is there any objection if I replace the usage in
CollectionBinder.bindFilters(boolean) with a single space (or maybe with
" \n\t" to produce more similar SQL as previous)?
Mark
--
Mark Rotteveel
6 years, 1 month
Re: [hibernate-dev] Form-feed (\f 0x0C) in generated SQL
by andrea boriero
And naturally a separate jira :)
On 7 Feb 2017 13:30, andrea boriero <andrea(a)hibernate.org> wrote:
> It's better to have a separate.
>
> On 7 Feb 2017 13:17, "Mark Rotteveel" <mark(a)lawinegevaar.nl> wrote:
>
> On 7-2-2017 14:12, Vlad Mihalcea wrote:
> > +1.
> >
> > I forgot to mention to add a Jira issue. If you don't have time, let me
> > know, and I'll take care of this issue for you.
>
> I was considering doing it as part of my Firebird dialect PR, but if you
> prefer a separate ticket + PR, I can do that as well.
>
> Mark
> --
> Mark Rotteveel
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
>
6 years, 1 month
Query#iterate
by Steve Ebersole
I know I started a discussion of this somewhere with some of you, but I
cannot find it anymore.
I had suggested we consider getting rid of this Query#iterate method. I
just wanted to get everyone's opinions of this. Specifically, getting of
it in 6.0.
If anyone has dug much into the current Antlr 2 based parser you will be
familiar with this idea of shallow versus non-shallow queries. That is
where this comes into play. Query#iterate is a shallow query
(shallow=true). All other queries are non-shallow.
There are quite a few internal reasons to simply drop that method and get
rid of the idea of this shallow flag. I am happy to discuss these reasons
for those interested and that do not know.
But obviously we should not be getting rid of things just because of
"internal complications" if they are used by many users. I cannot speak to
whether any users use this, let alone how many.
Thoughts?
6 years, 1 month
