Don't use range validator...

[Volnei]

... especially for large ranges!

Hi all,

I'm writing just to share with you my terrible experience with the range
validator.
I and my team are working on a large project myself with hundreds of domain
classes, all with their validators and we are very careful in assigning
them.

Well, part of this project was to produce in the last week and to our
surprise it was a terrible experience. Especially when having a transaction
insert into one of our domain classes . The server CPU reached 100 % and
stayed there while the performance falls every minute. I confess that I
felt frustrated.
We started investigating the causes of slowdowns and after exhausting any
possibility of the database, triggers, constraints, retentions, locks and
more... imagine that it could be something related to the behavior of
hibernate.
Again we did not have any developments, we read several times the GORM
Gotchas and some very good performances from Burt Beckwith, but we were
still with the problem .
The light at the end of the tunnel appeared when disabling validation with
a save (validate: false) and the application started to respond with a
satisfactory time. But did not make sense that some constraints could
generate so much delay.
Then investigated constraint by constraint and disabling one by one to
identify what was being more costly and came to the conclusion that it was
a range constraint we had in a field of a domain class. Something like this:

field range : 0 .. 9999999999

No biggie right? Wrong!

We understand what the operation of the range and to our surprise is not
something simple like a:

it> from && it < to

The Range of the Groovy class actually creates a list and runs the same to
see if the value is valid . Understand that I am not questioning the
operation of the same , only saying that her performance can be very
degrading . The following script takes only 1 milesegundo to run:

def r = 1 .. 9999999999
println r.contains ( 1 )

The same script to a larger value takes more than 1 second.

def r = 1..9999999999
println r.contains(20000000)

And with the maximum value takes up to 5 minutes.

Not terrible? After removing all constraints of range back to being
satisfied with this framework that fills my eyes. And that does not pass
through the same situation, I decided to share with you.

Enjoy!

[George Smith]

Why wouldn't you just use min:0, max:999999999 for that? It would never
occur to me to use a range for that.

Post by Volnei
... especially for large ranges!
Hi all,
I'm writing just to share with you my terrible experience with the range
validator.
I and my team are working on a large project myself with hundreds of
domain classes, all with their validators and we are very careful in
assigning them.
Well, part of this project was to produce in the last week and to our
surprise it was a terrible experience. Especially when having a transaction
insert into one of our domain classes . The server CPU reached 100 % and
stayed there while the performance falls every minute. I confess that I
felt frustrated.
We started investigating the causes of slowdowns and after exhausting any
possibility of the database, triggers, constraints, retentions, locks and
more... imagine that it could be something related to the behavior of
hibernate.
Again we did not have any developments, we read several times the GORM
Gotchas and some very good performances from Burt Beckwith, but we were
still with the problem .
The light at the end of the tunnel appeared when disabling validation with
a save (validate: false) and the application started to respond with a
satisfactory time. But did not make sense that some constraints could
generate so much delay.
Then investigated constraint by constraint and disabling one by one to
identify what was being more costly and came to the conclusion that it was
field range : 0 .. 9999999999
No biggie right? Wrong!
We understand what the operation of the range and to our surprise is not
it> from && it < to
The Range of the Groovy class actually creates a list and runs the same to
see if the value is valid . Understand that I am not questioning the
operation of the same , only saying that her performance can be very
def r = 1 .. 9999999999
println r.contains ( 1 )
The same script to a larger value takes more than 1 second.
def r = 1..9999999999
println r.contains(20000000)
And with the maximum value takes up to 5 minutes.
Not terrible? After removing all constraints of range back to being
satisfied with this framework that fills my eyes. And that does not pass
through the same situation, I decided to share with you.
Enjoy!