[hibernate-dev] ORM DDL doesn't reflect BV constraints with validation mode CALLBACK
steve at hibernate.org
Tue Feb 6 11:01:16 EST 2018
On Tue, Feb 6, 2018 at 9:43 AM Sanne Grinovero <sanne at hibernate.org> wrote:
> On 6 February 2018 at 15:34, Steve Ebersole <steve at 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
> > is that the in-memory validations will (a) happen and (b) pass and then
> > 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
More information about the hibernate-dev