I realize I could split Join and Fetch into different hierarchies.
That is what I want to try to avoid though...
On Wed 13 Jun 2012 02:55:03 PM CDT, Steve Ebersole wrote:
> I need some help with generic types in the JPA 2.1 API, specifically
> with regard to the new Join#on and Fetch#on methods.
I need some help with generic types in the JPA 2.1 API, specifically
with regard to the new Join#on and Fetch#on methods. We ultimately
unify those 2 interface hierarchies into a single hierarchy in out code
using org.hibernate.ejb.criteria.JoinImplementor which extends from both
Join and Fetc
So frustrating that we could do this so much cleaner if we were dealing
with syntax trees instead of strings. The dialect could just position
the limit parameter nodes correctly in the tree and that would be that.
Minor, but I'd like to see something other than
bindLimitParametersPreQuery and
On 13 Jun 2012, at 20:24, Steve Ebersole wrote:
> Well I think a great rule is the test suite. We actually have tests in
> ORM that inspect the exception message string to perform assertions.
> If you need the distinction for the test suite, its a good bet users
> might too ;)
Sounds like
Hello Guenther,
I totally agree that user could adapt his query to use "AS" keyword, while we
focus on keeping getLimitString() most fast and
simple as possible.
I think that my modifications are more or less ready and you can view them
here:
https://github.com/lukasz-antoniak/hibernate-core/
Well I think a great rule is the test suite. We actually have tests in
ORM that inspect the exception message string to perform assertions.
If you need the distinction for the test suite, its a good bet users
might too ;)
On Wed 13 Jun 2012 12:02:45 PM CDT, Emmanuel Bernard wrote:
> Year, it
Year, it was never a rule in search. It's just that we never had a need. At
least I never had a need. I am against artificial exception hierarchies for the
sake of separation but if there is a use case, let's go :)
On 13 juin 2012, at 15:26, Steve Ebersole wrote:
> I think thats a bad rule in g
I think thats a bad rule in general ;)
Lack of specific exception types in ORM has been an issue quite a few
times.
On Wed 13 Jun 2012 08:15:48 AM CDT, Sanne Grinovero wrote:
> Ok, only for this specific case I created:
> https://hibernate.onjira.com/browse/HSEARCH-1161
>
> So we won't have a si
Ok, only for this specific case I created:
https://hibernate.onjira.com/browse/HSEARCH-1161
So we won't have a single exception any more, I guess more will come
as needed now that the "single type exception" rule is broken.
Sanne
On 13 June 2012 13:57, Hardy Ferentschik wrote:
> +1 and as Emman
+1 and as Emmanuel is saying we should take it as it comes
On Jun 13, 2012, at 2:49 PM, Emmanuel Bernard wrote:
> +1 on a case by case basis. That can definitely help here.
>
> On 13 juin 2012, at 14:05, Sanne Grinovero wrote:
>
>> I'm wondering if we should specialize SearchException in some
+1 on a case by case basis. That can definitely help here.
On 13 juin 2012, at 14:05, Sanne Grinovero wrote:
> I'm wondering if we should specialize SearchException in some cases to
> make it easier for business logic to react correctly, like in the case
> of:
>
> https://bugzilla.redhat.com/sho
Yep, a schedule for syncing was never decided.
Thanks for investigating the specific here Hardy.
On Wed 13 Jun 2012 05:33:56 AM CDT, Hardy Ferentschik wrote:
>
> On Jun 13, 2012, at 9:43 AM, Strong Liu wrote:
>
>> are the master and metamodel supposed to be synced?
>
> Yes, but not automatically.
I'm wondering if we should specialize SearchException in some cases to
make it easier for business logic to react correctly, like in the case
of:
https://bugzilla.redhat.com/show_bug.cgi?id=831569#c2
Sanne
___
hibernate-dev mailing list
hibernate-dev@li
On Jun 13, 2012, at 9:43 AM, Strong Liu wrote:
> are the master and metamodel supposed to be synced?
Yes, but not automatically. The plan is to sync them regularly, but I don't
think we have determined yet how
often.
> I see there are some mismatch
>
> org.hibernate.internal.SessionFactoryI
Hi Alex,
I have a question in regard to class
ReadWriteEhcacheNaturalIdRegionAccessStrategy where you are listed as co-author.
Do you maybe know, why inserts do only succeed if there is no existing value
mapped to the actual key?
Code-snippet of ReadWriteEhcacheNaturalIdRegionAccessStrategy#aft
are the master and metamodel supposed to be synced?
I see there are some mismatch
org.hibernate.internal.SessionFactoryImpl#determineCustomEntityDirtinessStrategy
org.hibernate.internal.SessionFactoryImpl#determineCurrentTenantIdentifierResolver
these two methods only exist in master, but not in
16 matches
Mail list logo
