That sounds reasonable. So long as there is a property to control it from
persistence.xml, more people will be happy with it.
It would be very important to quote whatever error people will get in the
docs, so they can find the solution easier.
2016-09-21 22:03 GMT+03:00 Steve Ebersole :
> One ad
One additional thing we might consider is possibly unifying this 0- and 1-
based mismatch wrt JDBC-style parameters.
In Hibernate's APIs these JDBC-style parameters were 0-based. I have
already dropped support (it has been deprecated for a long time anyway) for
using JDBC-style params in HQL. So
I never said anything about dropping support for named and positional
parameters in native queries.
I simply mentioned leveraging the new "JPA strict compliance" stuff I am
adding to 6.0. The idea is to allow you to enable that and get feedback
when you use non-portable things.
On Tue, Sep 20,
You should refer him to the ticket I mentioned on HC
On Wed, Sep 21, 2016 at 11:19 AM Emmanuel Bernard
wrote:
> At least on the NoORM side, we do like what it provides and we do exchange
> a lot in it. It doesn’t have to be everyone’s best tool of course.
> The multi client including phone is a
Hi Petar,
you can use Identifier#toIdentifier(String text)
this method detects if the text is quoted and it calls
the Identifier#toIdentifier( String text , boolean quoted ) with the
correct quoted value.
On 21 September 2016 at 16:54, Petar Tahchiev wrote:
> Hey guys,
>
> I just created a
Thanks! Great catch. That was a bad setup, we will get it fixed.
On Wed, Sep 21, 2016 at 10:42 AM Jordan Gigov wrote:
> I mean this dependency in "buildscript"
>
> https://github.com/hibernate/hibernate-orm/blob/master/documentation/documentation.gradle#L22
>
> 2016-09-21 17:59 GMT+03:00 Steve
Hey guys,
I just created a pull-request for HHH-11089:
https://github.com/hibernate/hibernate-orm/pull/1564
However when I create the Identifier like this:
Identifier.toIdentifier( keyName, true );
I always set quoted to true as I don't know where to get this value from.
Can someone please ha
I mean this dependency in "buildscript"
https://github.com/hibernate/hibernate-orm/blob/master/documentation/documentation.gradle#L22
2016-09-21 17:59 GMT+03:00 Steve Ebersole :
> By "package buildscripts" do you mean the buildSrc module? That should
> not be the case.
>
> If not, what do yo mea
By "package buildscripts" do you mean the buildSrc module? That should not
be the case.
If not, what do yo mean by "package buildscripts"?
On Wed, Sep 21, 2016 at 9:47 AM Jordan Gigov wrote:
> Well, the CI would generally have a local snapshot to use, instead of
> downloading it.
> The probl
Well, the CI would generally have a local snapshot to use, instead of
downloading it.
The problem is that the package buildscripts depend on
'hibernate-gradle-plugin',but it depends on 'hibernate-core'.
I just cleared my ~/.gradle/caches and ~/.m2/repository/org/hibernate/,
switched to the '5.1' b
Well the only way I can see that happening is if you used different JDKs
between the runs. That is always a trigger to me (regardless of build
tool) that I have to clean first. Otherwise, I have no idea what might
have caused you to see that.
On Wed, Sep 21, 2016 at 9:31 AM Petar Tahchiev
wrot
Yes, clean worked. Thank you Steve and sorry about the noise - I'm not very
familiar with gradle.
2016-09-21 17:28 GMT+03:00 Steve Ebersole :
> Try a clean?
>
>
> On Wed, Sep 21, 2016 at 9:23 AM Petar Tahchiev
> wrote:
>
>> Yeah really strange - branch 5.0 and master (5.2.3) I can build without
Try a clean?
On Wed, Sep 21, 2016 at 9:23 AM Petar Tahchiev
wrote:
> Yeah really strange - branch 5.0 and master (5.2.3) I can build without a
> problem, but 5.1 shows that error.
>
> 2016-09-21 17:17 GMT+03:00 Steve Ebersole :
>
>> Strange. It is working in CI:
>> http://ci.hibernate.org/view
Yeah really strange - branch 5.0 and master (5.2.3) I can build without a
problem, but 5.1 shows that error.
2016-09-21 17:17 GMT+03:00 Steve Ebersole :
> Strange. It is working in CI: http://ci.hibernate.org/
> view/ORM/job/hibernate-orm-5.1-h2/
>
>
> On Wed, Sep 21, 2016 at 9:03 AM Petar Tahch
Strange. It is working in CI:
http://ci.hibernate.org/view/ORM/job/hibernate-orm-5.1-h2/
On Wed, Sep 21, 2016 at 9:03 AM Petar Tahchiev
wrote:
> Hi guys,
>
> I'm trying to build the 5.1 branch with "./gradlew publishToMavenLocal" but
> I get the following error:
>
> :hibernate-ehcache:generate
Hi guys,
I'm trying to build the 5.1 branch with "./gradlew publishToMavenLocal" but
I get the following error:
:hibernate-ehcache:generatePomFileForMavenJavaPublication
:hibernate-ehcache:compileJava
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation
Check out this Jira issue that I integrated today:
https://hibernate.atlassian.net/browse/HHH-11120
If we enable this property, all the underlying resources are released right
away.
Otherwise (the default option), resources are released when the transaction
is ended (commit/rollback).
If this fi
At least on the NoORM side, we do like what it provides and we do exchange a
lot in it. It doesn’t have to be everyone’s best tool of course.
The multi client including phone is an awesome feature for my flow for example.
I’ve contacted Samuel and he offered options to give it a shot.
Emmanuel
I have no idea what "I could make use of it" means in this context. Make
use of what? That setting? That setting has zero effect today, unless I
missed something.
On Wed, Sep 21, 2016 at 8:33 AM Vlad Mihalcea
wrote:
> I could make use of it in a non-JTA environment. I guess we need to think
>
I could make use of it in a non-JTA environment. I guess we need to think
what should we do with the transaction status because now it's still
active, but if we try to rollback, we'll get an exception because the
connection was closed.
Vlad
On Wed, Sep 21, 2016 at 4:30 PM, Steve Ebersole wrote:
Sorry, *was* only valid for JTA. As you mentioned we handle this
differently today.
On Wed, Sep 21, 2016 at 8:29 AM Steve Ebersole wrote:
> DISCARD_PC_ON_CLOSE, as a concept, is only valid for JTA iirc.
>
> On Wed, Sep 21, 2016 at 8:11 AM Vlad Mihalcea
> wrote:
>
>> Hi,
>>
>> While reviewing
DISCARD_PC_ON_CLOSE, as a concept, is only valid for JTA iirc.
On Wed, Sep 21, 2016 at 8:11 AM Vlad Mihalcea
wrote:
> Hi,
>
> While reviewing and adding a test case for
> https://hibernate.atlassian.net/browse/HHH-11120,
> I realized that if we enable the AvailableSettings.DISCARD_PC_ON_CLOSE
>
I thought we had some sort of non-basic license already. Isn't that why we
need to explicitly invite people to be non-Guest?
Anyway, I agree wrt HipChat being more or less useless. I've been saying
that for a while now. Yes the GitHub and Jira and social integrations *can
be* nice (they can als
+1
On 09/20/2016 08:59 PM, Steve Ebersole wrote:
> In the interest of questioning everything, just to make sure we are all on
> the same page, Hibernate's support for native SQL queries currently
> recognizes named parameters, positional parameters as well as JDBC-style
> parameters.
>
> JPA only
Hi,
While reviewing and adding a test case for
https://hibernate.atlassian.net/browse/HHH-11120,
I realized that if we enable the AvailableSettings.DISCARD_PC_ON_CLOSE
property,
the database connection gets closed when the EntityManager is closed, while
the EntityTransaction status remains ACTIVE.
Hi all,
I've updated the Java 9 preview build on our ci.hibernate.org build
servers to version 9-ea+136.
There's a catch: the build option which we've been using "-addmods"
has been renamed "--add-modules".
We need to update all build scripts; I'm taking care of Search and
OGM, I hope others can
Steve, all,
Is there any way we can get HipChat Plus licenses for the team from
Atlassian?
The free client provides access only to a limited part of the chat history,
making it impossible to search for discussions discussed more than a few
weeks ago.
That's starting to be a real problem now that
Hi all,
I just happened to build Hibernate ORM's latest "master" on a clean
machine and this is how the build log looks like:
No compatible daemons found:
- an idle daemon with different JVM constraints can't run this build
Starting a new Gradle Daemon for this build: subsequent builds will be
+1
On 21 Sep 2016 02:00, "Steve Ebersole" wrote:
> In the interest of questioning everything, just to make sure we are all on
> the same page, Hibernate's support for native SQL queries currently
> recognizes named parameters, positional parameters as well as JDBC-style
> parameters.
>
> JPA onl
Thanks, I know that it's a beauty ^^
Hope this can get into all 5.x branches?
Regards,
Christian
Am 20.09.2016 um 23:05 schrieb Steve Ebersole:
> I took a quick look. I'd prefer to see better solution as we migrate
> to SQM; but for 5.x, given how Hibernate generates SQL there, I am not
> sure
30 matches
Mail list logo
