Looks like that's the previous discussion Steve was referring to:
http://lists.jboss.org/pipermail/hibernate-dev/2012-January/007625.html
2015-04-30 5:41 GMT+02:00 Steve Ebersole :
> https://hibernate.atlassian.net/browse/HHH-9761
>
> On Wed, Apr 29, 2015 at 8:16 AM, Steve Ebersole
> wrote:
>
>
http://in.relation.to/Bloggers/HibernateORM500Beta2Release
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
https://hibernate.atlassian.net/browse/HHH-9761
On Wed, Apr 29, 2015 at 8:16 AM, Steve Ebersole wrote:
> We discussed this before on the list. The main thing to decide is
> Session#load and proxies. Basically there are times when:
>
> public T load(Class entityType, Object id)
>
> simply will
https://hibernate.atlassian.net/browse/HHH-9760
On Wed, Apr 29, 2015 at 8:21 AM, Steve Ebersole wrote:
> Yes, I think that logic is not correct. A bigger concern I have there tbh
> is HEM; there is some very fragile (at best) code that tries to "decode"
> the exceptions thrown by the native API
This mailing list is for discussing Hibernate development. Please open a JIRA
issue at https://hibernate.atlassian.net/projects/HHH and attach your test.
Thanks,
Gail
- Original Message -
> From: "Mihalcea Vlad"
> To: "Hibernate Dev"
> Sent: Wednesday, April 29, 2015 7:01:11 AM
> Subjec
Ok, I'll call it a quorum in terms of making this Beta2...
On Wed, Apr 29, 2015 at 12:02 PM, Steve Ebersole
wrote:
> WRT performance testing... well I think we can agree that the performance
> would not be worse. So I don't see the harm in that regard.
>
> On Wed, Apr 29, 2015 at 11:15 AM, Sann
WRT performance testing... well I think we can agree that the performance
would not be worse. So I don't see the harm in that regard.
On Wed, Apr 29, 2015 at 11:15 AM, Sanne Grinovero
wrote:
> On 29 April 2015 at 16:54, Steve Ebersole wrote:
> > For EntityKey vs CacheKey, that reminds me... ha
On 29 April 2015 at 16:54, Steve Ebersole wrote:
> For EntityKey vs CacheKey, that reminds me... have we ever unified the
> differing notions of a "cache key"? Aka, just have the RegionFactory build
> CachKeys for us so that we don't have to always be re-wrapping...
Right that's what I'm referri
I agree with the Beta2 in order to give time to try out the Transaction
Changes :)
+1
On 29 April 2015 at 16:20, Steve Ebersole wrote:
> I had originally planned on today's release being the first CR for 5.0. I
> am re-thinking that now. Here is why...
>
> 1) If we were to ever start offering
For EntityKey vs CacheKey, that reminds me... have we ever unified the
differing notions of a "cache key"? Aka, just have the RegionFactory build
CachKeys for us so that we don't have to always be re-wrapping...
On Wed, Apr 29, 2015 at 10:49 AM, Sanne Grinovero
wrote:
> I would love that as I s
I would love that as I should really check on two last things but
couldn't make time yet.
- the Locking API
- checking if what I'm having in mind regarding EntityKey vs CacheKey
needs any API change
+1 for a little extra time
Thanks!
Sanne
On 29 April 2015 at 16:22, Steve Ebersole wrote:
> Oh
Oh... and I'd *like* to get the Karaf features file figured out. Not
blocker, but a nice to have.
On Wed, Apr 29, 2015 at 10:20 AM, Steve Ebersole
wrote:
> I had originally planned on today's release being the first CR for 5.0. I
> am re-thinking that now. Here is why...
>
> 1) If we were to
I had originally planned on today's release being the first CR for 5.0. I
am re-thinking that now. Here is why...
1) If we were to ever start offering a typed API, a major major release
would be the time to do that. However, we'd still have the "load() + proxy
interfaces" issue to decide a cour
Hi,
Setting the "hibernate.cache.default_cache_concurrency_strategy" property
doesn't have any effect.
This setting is inspected in
AnnotationBinder.prepareDefaultCacheConcurrencyStrategy method, but thatmethod
is never called.
Here's a test to replicate the issue:
https://github.com/vladmihalc
Yes, I think that logic is not correct. A bigger concern I have there tbh
is HEM; there is some very fragile (at best) code that tries to "decode"
the exceptions thrown by the native APIs. That stuff could very easily
break.
On Tue, Apr 28, 2015 at 4:32 PM, Gunnar Morling
wrote:
> TransactionI
We discussed this before on the list. The main thing to decide is
Session#load and proxies. Basically there are times when:
public T load(Class entityType, Object id)
simply will not work. This is the discussion I started wrt annotating the
proxy interface, rather than the impl class.
Basical
Yes I think a 5.x supporting ORM 5 would be my preference. I sort of remember
us discussing that option in AMS.
> On 29 Apr 2015, at 12:42, Sanne Grinovero wrote:
>
> Ok so we have all been wrong, but also we couldn't wait.
> Looking forward, does this mean you'd prefer to upgrade to ORM 5 in a
Ok so we have all been wrong, but also we couldn't wait.
Looking forward, does this mean you'd prefer to upgrade to ORM 5 in a
minor version of Hibernate Search?
Sanne
On 29 April 2015 at 10:07, Emmanuel Bernard wrote:
> I liked and still do like the planet alignment to make the major a platform
Hi Vlad,
That’s an interesting proposal. It is certainly possible. But since the Session
and Query API (Hibernate native) is historically non typed, I wonder if that is
worth introducing these new typed version and add more overloaded methods on
Session.
Do you think it is worth the additional
I liked and still do like the planet alignment to make the major a platform
signal. But when we discussed it, you all were against me.
> On 22 Apr 2015, at 10:41, Sanne Grinovero wrote:
>
> Just a heads up: I'm not seeing the question from the subject often enough.
>
> In fact, I only see it w
20 matches
Mail list logo
