Steve,
thank you very much. The test is extremely simple and as a programmer I
thought those few lines of code would clear up any confusion.
It's perfectly OK to postpone the discussion and I will be very happy to
continue once the problem is reproduced and understood.
Once again thank you for
Ok, I didn't expect that those issues with Gradle would still be unresolved.
Thanks
On 7 June 2016 at 13:47, Steve Ebersole wrote:
> I have mentioned this before. We cannot automate this through Gradle (long
> story, feel free to see my Gradle Jiras and forum posts for details). And I
> am not
On 8 June 2016 at 16:08, Gunnar Morling wrote:
> It'd not only be a library, but an image containing WF with the latest
> Hibernate ORM. But as said, the module ZIP is more versatile and is what I'd
> do.
+1 for the priority on ZIP files.
I had not understood that you meant to re-distribute a cu
It'd not only be a library, but an image containing WF with the latest
Hibernate ORM. But as said, the module ZIP is more versatile and is what
I'd do.
2016-06-08 16:59 GMT+02:00 Sanne Grinovero :
> On 8 June 2016 at 08:11, Gunnar Morling wrote:
> > 2016-06-07 15:51 GMT+02:00 Steve Ebersole :
>
I don't know. I was just thinking of distribution. I really know very
little about WF modules
On Wed, Jun 8, 2016 at 9:59 AM Sanne Grinovero wrote:
> On 8 June 2016 at 08:11, Gunnar Morling wrote:
> > 2016-06-07 15:51 GMT+02:00 Steve Ebersole :
> >
> >> Too bad we can't just publish a Docker i
On 8 June 2016 at 08:11, Gunnar Morling wrote:
> 2016-06-07 15:51 GMT+02:00 Steve Ebersole :
>
>> Too bad we can't just publish a Docker image.
>>
>
> We could do that, but I think we should have a solution for non-Docker
> users, too.
What's the point to package a library in a Docker image?
>
>
On 8 June 2016 at 15:06, Steve Ebersole wrote:
> Well the reasoning was discussed on this list and everyone agreed :) It
> was part of a larger discussion about releases and maintaining maintenance
> branches. But if everyone, I am ok with doing CR (only) for minor releases.
>
> Part of the reas
So I think we all agree that a hybrid approach is a good think, but the
only drawback is that the release takes time and Steve is the only one in
charge to make this release.
Is it possible to have one more person that is allowed to initiate a
RC release?
The release burden should be shared.
Vlad
On Wed, Jun 8, 2016 at 9:20 AM Vlad Mihalcea
wrote:
> If there is a backward incompatibility issue, we catch it in the CR
> release and, by the time we release Final, we know we got it fixed.
>
If I had to guess, this is what Spring Data devs are more interested in.
We have been doing a lot of r
I think it's just about what our users expect from a Final release. If we
mark a release with the CR suffix, people will know this might have bugs
and they can help us identify them before we release the Final version.
If there is a backward incompatibility issue, we catch it in the CR release
and,
+1 for the hybrid approach if we feel we need minor release CRs.
On 06/08/2016 09:06 AM, Steve Ebersole wrote:
> back to this then I vote that we also go for a hybrid approach to this
> where Final is an approximation of the "approved CR", likely with
> additional fixes.
>
__
Thanks for the tip. I didn't know about it. I'll give it a try then.
On Wed, Jun 8, 2016 at 5:07 PM, Steve Ebersole wrote:
> You mean like a org.hibernate.resource.jdbc.spi.StatementInspector?
>
> On Wed, Jun 8, 2016 at 6:47 AM Vlad Mihalcea
> wrote:
>
>> Hi,
>>
>> During testing, it's very use
You mean like a org.hibernate.resource.jdbc.spi.StatementInspector?
On Wed, Jun 8, 2016 at 6:47 AM Vlad Mihalcea
wrote:
> Hi,
>
> During testing, it's very useful to have an SQL query interceptor that we
> can inspect to see if the generated SQL query contains a certain SQL
> clause.
> There are
Well the reasoning was discussed on this list and everyone agreed :) It
was part of a larger discussion about releases and maintaining maintenance
branches. But if everyone, I am ok with doing CR (only) for minor releases.
Part of the reasoning was that technically speaking a Final really ought
Sanne, you just said it.. the reason you did not test with 5.2 before it
was released is time. Me doing a CR release does not change that. The
stuff that "bit you" in 5.2 was available for testing for well over a month
prior to releasing 5.2. And it's not like 5.2 was released without
discussion
the annotation was introduced with
https://hibernate.atlassian.net/browse/HHH-6841
the reason seems to provide the ability add different reasons for each
Dialect.
On 8 June 2016 at 14:19, Vlad Mihalcea wrote:
> Hi,
>
> While writing a cross-dialect test, I bumped into the following issue:
>
> h
Hi,
While writing a cross-dialect test, I bumped into the following issue:
https://hibernate.atlassian.net/browse/HHH-10814
The question is why do we have a @RequiresDialects annotation:
@RequiresDialects({
@RequiresDialect(PostgreSQL81Dialect.class),
@RequiresDialect(Oracle8iDialect.cl
+1
I've also hit some incompatible API changes which I only figured out
too late (when attempting to upgrade Hibernate Search).
I could have pre-tested snapshot builds but didn't have time for that
- and didn't expect 5.2 to be released without a Beta period, or I
would have made time for that.
Hi,
During testing, it's very useful to have an SQL query interceptor that we
can inspect to see if the generated SQL query contains a certain SQL clause.
There are multiple ways we could implement this kind of feature:
1. We could add a public String[] getSQLQueries(); in the Statistics
interfac
My modest contribution
https://hibernate.atlassian.net/browse/HHH-10813
https://github.com/hibernate/hibernate-orm/pull/1408
Emmanuel
> On 07 Jun 2016, at 15:25, Steve Ebersole wrote:
>
> I agree that the wording should be changed. That sentiment is true of many,
> many exceptions.
>
>
> O
Does the HQL to native query mechanic use this too?
> On 08 Jun 2016, at 08:50, Gunnar Morling wrote:
>
> JavaTypeDescriptorRegistry is used by Hibernate OGM in
> (o.h.o.type.impl.TypeTranslatorImpl).
>
>> From my side, the proposed change is good, esp. if it fixes some existing
> bugs. It'd lo
MetamodelGraphWalker line 144. My relation is in
MetamodelGraphWalker.visitedAssociationKeys, so it gets skipped and thus
not make it in the final big SQL SELECT.
Why don't you take a look at the test case I provided - just run it and
see the LazyInitializationException error, it will all be in
2016-06-07 15:51 GMT+02:00 Steve Ebersole :
> Too bad we can't just publish a Docker image.
>
We could do that, but I think we should have a solution for non-Docker
users, too.
>
> Is this something we'd publish somewhere (Nexus/Artifactory)?
>
Yes, we'd publish it in Nexus and also BinTray/Sou
Hi,
I have seen the frustration from the Spring Data team trying to keep up
with our code changes that break their integrations,
and I was wondering if we should use some Release candidates prior to
releasing a start of a branch, even if it's a minor one.
This way, instead of 5.2.0, we could relea
24 matches
Mail list logo
