> On 30.10.2014, at 23:43, Steve Ebersole wrote:
>
> Well telling me/us which PRs got closed would be a good first step :)
Here are mines:
https://github.com/hibernate/hibernate-orm/pull/779
https://github.com/hibernate/hibernate-orm/pull/782
https://github.com/hibernate/hibernate-orm/pull/777
Well telling me/us which PRs got closed would be a good first step :)
Overall, checking that the PR still applies is a good idea too.
On Thu, Oct 30, 2014 at 5:34 PM, Andrej Golovnin wrote:
>
> > On 30.10.2014, at 23:15, Steve Ebersole wrote:
> >
> > Well maybe rather than being hurt and sensi
I've finished with the releases, including uploading everthing. I'm having
trouble setting up the weblog entry in in.relation.to for some reason. I'll
blog about the releases tomorrow.
Regards,
Gail
___
hibernate-dev mailing list
hibernate-dev@lists.jbo
Hello Steve,
you have closed my pull requests and
pull requests from others too without any comment.
Should we create a new pull requests for the "new master" branch?
Or should we just forget all the time and the work we have invested
to create those pull requests and stop submitting any new pull
We are getting closer to a final release and this version is mainly about
improving general performance and reducing the amount of round trips to the
datastore.
We also added optimistic locking support for datastores which provide
atomic find-and-update operations.
You can read more about it in t
Hi Guillaume,
excellent!
I think 5.0.0.Alpha7 already includes your fix, but we're releasing
Beta1 in one or two days.
We didn't do Beta releases so far as we where hoping to make some more
API changes in the 5.0 sprint but we just decided (we're having a face
to face meeting this week) to scrap t
Guillaume, it depends unfortunately. In distributed cases, checking the
status of a transaction could mean remote calls. That's why I was saying
I'd rather not have the unnecessary overhead if not needed.
On Thu, Oct 30, 2014 at 9:51 AM, Guillaume Smet
wrote:
> On Thu, Oct 30, 2014 at 2:56 PM,
It was decided that the massive work for 5.0 including metamodel and all
the other changes was just taking too long, and that we'd split that work
up into a number of intermediate versions. I wanted to highlight the
proposed breakdown and solidify the roadmaps. The preliminary breakdown is
as fol
On Thu, Oct 30, 2014 at 2:56 PM, Steve Ebersole wrote:
> Personally having entities dirtied as part of a read-only transaction sounds
> like an application bug to me. We could try to detect a read-only
> transaction state (not sure how we'd do that across all cases) and
> circumvent the flush the
Personally having entities dirtied as part of a read-only
transaction sounds like an application bug to me. We could try to detect a
read-only transaction state (not sure how we'd do that across all cases)
and circumvent the flush there, but that would add unnecessary overhead to
applications that
Hi Sanne,
On Fri, Aug 22, 2014 at 11:25 PM, Guillaume Smet
wrote:
> We'll have the bandwidth starting from september 15th so if we have a
> release then, we'll start playing with 5.
If a new alpha of 5 can be released soon with the above fix, we will
be able to start using it in our in progress
Hi!
Starting with HHH-8487, when we execute a native query, an auto-flush
is executed (and might be limited with addSynchronizedEntityClass and
allegates).
While I understand the rationale of this change, we are having a few
issues with this when the transaction opened is read-only which is the
c
Please do not push anything to 4.2 and 4.3 branches until they are released.
Thanks,
Gail
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
13 matches
Mail list logo
