Re: [hibernate-dev] Hibernate Commons project
by Guillaume Smet
On Mon, Jan 30, 2017 at 3:26 PM, Yoann Rodiere <yrodiere(a)redhat.com> wrote:
>
> On 30 January 2017 at 13:58, Guillaume Smet <guillaume.smet(a)gmail.com>
> wrote:
>
>> Note that the current version of hibernate-commons-annotations is
>> org.hibernate.common (without the s at the end, not org.hibernate as Yoann
>> stated it).
>>
> You're right. Wouldn't the simplest solution be to use the same groupId
> (without a "s") in our new repo?
>
I'm not so sure it's a good idea to share the groupId while it being a
completely different project.
I'm starting to think that maybe the good groupId for these common internal
projects could be org.hibernate.*internal*. We plan them to be purely
internal artifacts and we might as well state it.
What do you all think about it?
> Moving hibernate-commons-annotations is not such a good idea IMHO:
>> - it's licensed under the LGPL so it would force us to use this license
>> (or
>> relicense it or having different licenses for the submodules but they are
>> all bad ideas)
>>
>
> It sure seems complicated. But relicensing from LGPL to ASL2 may not be
> such a big deal, since LGPL seems stricter than ASL2.
> Couldn't we simply dual-license the whole repository under ASL2/LGPL? That
> way, previous users wouldn't need to be aware of the change, and new users
> could choose to comply with whichever suits them best.
>
Yeah, dual licensing might be the better solution. But I think it would be
OK with ASL2. Anyway, let's wait for Emmanuel to decide on this subject.
> - we would release a new version of this module each time we want to
>> upgrade the theme and I don't think it would be readable for consumers of
>> this preexisting artifact.
>>
>> The latter point is what worries me about centralizing all the utils in
>> the
>> same repo with the same lifecycle.
>>
>
> We already got through this discussion, but let's sum it up:
>
Not exactly. I was specifically talking about hibernate-commons-annotations
as it's a different beast: it's already released and people might use it in
their projects. Thus I don't think it's a good idea to think of it as a
purely internal project.
IMHO, it makes a difference.
--
Guillaume
8 years, 11 months
Re: [hibernate-dev] Form-feed (\f 0x0C) in generated SQL
by Mark Rotteveel
Yes, it is the jdk9 job. Sorry, that I forgot to include that info.
Mark
----- Bericht beantwoorden -----
Van: "Steve Ebersole" <steve(a)hibernate.org>
Aan: "Mark Rotteveel" <mark(a)lawinegevaar.nl>, "Sanne Grinovero" <sanne(a)hibernate.org>
CC: "Hibernate.org" <hibernate-dev(a)lists.jboss.org>
Onderwerp: [hibernate-dev] Form-feed (\f 0x0C) in generated SQL
Datum: di, feb. 7, 2017 20:11
From which job? The JDK 9 one? Those failures you can ignore
On Tue, Feb 7, 2017, 11:52 AM Mark Rotteveel <mark(a)lawinegevaar.nl> wrote:
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
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
8 years, 11 months
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
8 years, 11 months
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
8 years, 11 months
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
>
>
>
8 years, 11 months
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?
8 years, 11 months
