On Tue, Feb 6, 2018 at 9:43 AM Sanne Grinovero <sanne(a)hibernate.org> wrote:
On 6 February 2018 at 15:34, Steve Ebersole
<steve(a)hibernate.org> wrote:
> We tend to do this argument where it "not what we would do". Well not
> everyone is us :)
Not understanding what you mean with that. I'm well aware others might
have other opinions, in fact I'm suggesting to allow people more
control than what you established should be right?
Is it valid for a user to want *just* DDL-based validation? How would that
work in Gunnar's request?
That's my point. I mean to me there is:
1. No validation
2. In-memory validation
3. In-db validation
4. In-memory && in-db validation
All of those are valid options. But I think Gunnar's suggestion misses #3,
although I certainly maybe just missed that in his email. Gunnar?
> Also you are arguing about optimizing the exception case. The
majority
case
> is that the in-memory validations will (a) happen and (b) pass and then
we
> still have the db validations happening.
I'm aware. And that's why I said "it might be redundant ... but then
you'd not need validation".
Obviously everyone needs validation, so optimising the exception case
might be important - especially since like I said it's much cheaper to
do so in in local memory rather than have a round trip to the RDBMS to
figure it out, and consume precious RBDMS resources to have it do the
same job.
1. No its not "obvious everyone needs validation". I've worked on a few
"raw input" systems (data imports, data transfers, etc) where you'd
actually want absolutely no validation. I'm sure there are other stories
out there where conditions call for no validation..
2. "so optimising the exception case *might* be important" - might,
absolutely. And then the rest of this comment... I mean you assume so many
things about that app, the environment, etc