On Wed, 1 Jan 2003, Andrus wrote:
> At 11:53 AM 1/2/2003 +1300, Craig Miskell wrote:
> ><rant-mode>Arrgghhhhhh..... unless mysql is *explicitly* compiled with
> >-DDONT_USE_DEFAULT_FIELDS (and I'm not keen on trying to compile said
> >beast on my windows box... yuck), any integer type fields declared as NON-NULL
> >will have a DEFAULT value of 0.... so if no value is supplied in the
> >insert statement (e.g. a foreign key field, say gallery_id in the exhibit
> >table in the unittests maybe.... ;-)), then a default value is inserted.
> >No, this is not considered an error by mysql, despite the data integrity
> >issues this most clearly raises. Unless you feel like recompiling it
> >yourself.
> Could you identify the place in the code where Cayenne relies on the
> implicit value (exhibit without a gallery?). Normally Cayenne should send
> "NULL" explicitly when required. Maybe before we dig deeper into validation
> etc., we should fix this and use NULL when building inserts/updates?
I wish it were that simple. However, for non-null columns with a default
value, if you pass null, it still puts the default value in anyway.
Unless I've missed something fundamental, I don't think this problem can
truly be fixed unless we implement at least some trivial validation
(although the whole shebang would probably take about as long as just
enough to fix this issue).
There is one solution: "TEXT" primary keys... if they are marked
"non-null" then they truly must be non-null, as they cannot have a default
value. But that's not a good idea, especially not just to work around
this issue.
> >This was at least one of the problems that was thrown up with my recent
> >changes (I created an exhibit without a gallery). Maybe it's time we had
> >client-side validation against the DataMap at commit time... configurable
> >on or off in case the end-developer wishes to just use the DB level error
> >checking, no matter how obtuse the java.sql.Exception messages may be.
> >My next project perhaps?
>
> This maybe a cool add-on. IIRC we discussed it in September on this list.
> Ironically after that I tried using EOValidation in WebObjects as a
> customizable validation mechanism for the first time in my long WO
> experience. Despite some ugliness catching and rethrowing validation
> exceptions, this works and is an o.k. way to handle validation.
Hmmm, add-on is a good way to look at it. It certainly adds some overhead
(especially when modifying lots of objects, which I'd wager is not
uncommon), and overhead that the dbserver will do anyway. As "additional
optional" behaviour, it leaves the power in the developers hands.
The big advantage I see to doing it before sending the SQL is that all
modified/inserted/(deleted?) objects can be validated, and a *list* of
problems returned. The UI then has the option of highlighting a bunch of
issues, not just the first one encountered (as it is now - when the commit
fails, only the first problem is reported, because that is all that is
known about)
I'll give it some more thought and see where it leads me. As usual design
will probably be 9/10 the battle :-)
Craig
This archive was generated by hypermail 2.0.0 : Wed Jan 01 2003 - 21:11:29 EST