On 15 mai 2012, at 23:51, Andrej Golovnin wrote:
> One more thing: Could we have a property similar to
> "hibernate.listeners.envers.autoRegister"
> for Validator? I would like to disable Validator completely as it produces
> too much garbage
> (look at the pictures) when the application is dep
On May 15, 2012, at 11:51 PM, Andrej Golovnin wrote:
> 1. Consider avoiding usage of String#toLowerCase() and String#toUpperCase()
>without specifying a Locale. Users running Hibernate on systems with
> Turkish as default
>locale may see unexpected results. In Turkish there are two lower
On 16 May 2012 10:47, Hardy Ferentschik wrote:
>
> On May 15, 2012, at 11:51 PM, Andrej Golovnin wrote:
>
>> 1. Consider avoiding usage of String#toLowerCase() and String#toUpperCase()
>> without specifying a Locale. Users running Hibernate on systems with
>> Turkish as default
>> locale ma
According to JPA 2.0 specification section 3.2.7.1, when merging a
detached entity with lazy associations that haven't been fetched:
"
The persistence provider must not merge fields marked LAZY that have not
been fetched: it must ignore such fields when merging.
"
After merging an entity, will
On 05/15/2012 05:51 PM, Andrej Golovnin wrote:
> Hi all,
>
> finally I have found the cause of this problem.
>
> But before I describe what caused it, I would like to make two suggestions:
>
> 1. Consider avoiding usage of String#toLowerCase() and String#toUpperCase()
> without specifying a Lo
On 16 mai 2012, at 14:28, Scott Marlow wrote:
> According to JPA 2.0 specification section 3.2.7.1, when merging a
> detached entity with lazy associations that haven't been fetched:
>
> "
> The persistence provider must not merge fields marked LAZY that have not
> been fetched: it must ignore
On 05/16/2012 10:16 AM, Emmanuel Bernard wrote:
>
> On 16 mai 2012, at 14:28, Scott Marlow wrote:
>
>> According to JPA 2.0 specification section 3.2.7.1, when merging a
>> detached entity with lazy associations that haven't been fetched:
>>
>> "
>> The persistence provider must not merge fields ma
On 05/16/2012 11:00 AM, Scott Marlow wrote:
> On 05/16/2012 10:16 AM, Emmanuel Bernard wrote:
>>
>> On 16 mai 2012, at 14:28, Scott Marlow wrote:
>>
>>> According to JPA 2.0 specification section 3.2.7.1, when merging a
>>> detached entity with lazy associations that haven't been fetched:
>>>
>>> "
On 16 May 2012 16:15, Scott Marlow wrote:
> On 05/16/2012 11:00 AM, Scott Marlow wrote:
>> On 05/16/2012 10:16 AM, Emmanuel Bernard wrote:
>>>
>>> On 16 mai 2012, at 14:28, Scott Marlow wrote:
>>>
According to JPA 2.0 specification section 3.2.7.1, when merging a
detached entity with laz
Hi Emmanuel,
>javax.persistence.validation.mode NONE
>
> should already do that ie disable the integration between JPA and Bean
> Validation. If that's not the case, there is a bug somewhere but I could not
> spot it.
>
> However, Bean Validation has to be activated by the EE container as
On 05/16/2012 01:40 PM, Andrej Golovnin wrote:
> Hi Emmanuel,
>
>> javax.persistence.validation.mode NONE
>>
>> should already do that ie disable the integration between JPA and Bean
>> Validation. If that's not the case, there is a bug somewhere but I could not
>> spot it.
>>
>> However, Bea
Hi Scott,
> Validation-mode is part of the JPA 2.0 spec and its not a property.
>
> Try adding:
>
> NONE
you are absolutely right. I think I was blind. I don't understand
how could I overlook it.
Thanks!
Best regards,
Andrej Golovnin
___
hibernate-d
On 05/16/2012 02:32 PM, Andrej Golovnin wrote:
> Hi Scott,
>
>> Validation-mode is part of the JPA 2.0 spec and its not a property.
>>
>> Try adding:
>>
>> NONE
>
> you are absolutely right. I think I was blind. I don't understand
> how could I overlook it.
>
> Thanks!
No worries, its very easy to
Hi Scott,
>
> Nice find! Could you drill into one of the LockMode loaders and see what the
> larger objects referenced by that are?
>
Largest objects are of type BatchingEntityLoader.
The problem has to do with the value of hibernate.default_batch_fetch_size.
In our case we use 16 as the val
Hi Hardy,
>> 1. Consider avoiding usage of String#toLowerCase() and String#toUpperCase()
>> without specifying a Locale. Users running Hibernate on systems with
>> Turkish as default
>> locale may see unexpected results. In Turkish there are two lowercase
>> letters
>> \u0069 ‘i’ and \u01
Well another option is to change the way batch load sql is
created/handled which is something that has come up many times before,
and someone was just discussing on the list last few weeks.
Given a batch size, Hibernate currently generates a non-unintuitive
number of loaders. Lets look at an e
actually, thinking about it more, not so sure the "reusing keys"
approach would not work.
On Wed 16 May 2012 04:35:36 PM CDT, Steve Ebersole wrote:
> Well another option is to change the way batch load sql is
> created/handled which is something that has come up many times before,
> and someone w
> Its been proposed a number of times to instead generate just a single
> loader for loading that number of items. This would mean generating a
> single SQL statement that has parameter holders for the full batch size
> and then somehow "filling out" the empty slots when the number of things
One option we use on our uPortal installs is to enable
-XX:+UseCompressedStrings
It requires a bit more CPU but we are generally memory bound and not CPU
bound. The description reads "Use a byte[] for Strings which can be
represented as pure ASCII. (Introduced in Java 6 Update 21 Performance
R
19 matches
Mail list logo
