I think I'm pretty much in agreement with this advice, primarily because of your last line: Some means of annotating constraints is the solution, but what form it should take is a hard question.

That's the million dollar question that most cannot solve for any reasonbly complex system. For constraints which are clearly global (your password can never be longer than 32 characters), then it's OK to trap and report them in client code. The problem with allowing the database errors to bubble up is that you theoretically want to parse the error message to make it more understandable to a user.

For my work, I want to follow that Pareto rule: 80% of your results stem from 20% of your actions. With this, if I can properly identify the most common errors users are likely to commit, I focus on eliminating the possibility then can commit these (give them a country drop down intead of a text field where they can type the country name) or give them a useful error message for the common cases rather than ever hit the database. Those situations, when properly identified and combined with an intuitive interface, should ameliorate the bulk of application problems. For situations you've not anticipate/covered, you'll have to figure out a reasonable solution and what that solution is generally needs to be customized for an application as "one size fits all" approaches generally mean "one size fits none".

Fortunately, with a well-designed database, many of the constraints are easy to identify. One-to-many relationships imply a select list if you're using HTML. Length constraints in fields imply that you can easily push those constraints to forms (try entering long passwords on Perlmonks, for example, even though you can theoretically enter a longer one). Data level constraints (age must be greater than 20 and less than 65) are more difficult to handle in a generic matter. Whether or not it's worth the programmers time to handle all of those depends upon your business needs.

Don't take this as criticism, though. I completely agree with what you're saying. I'm just filling in some detail :)

This _is_ a hard problem, but I personally believe that an elegant solution will present itself some day. I've always assumed the solution would be either to generate some parts of the application code from the db schema, or generate the schema from the application code, or both from a common source (like a sql schema with annotations).

There are lots of partial solutions like this (eg the *::Loader modules to read the schema. Solutions like DBIx::DBO2::Fields to set column level contstraints (its in the TODO to read these from the db schema). But I've not seen anything that puts it all together.

I think what’s really necessary is basically for things that talk SQL to acknowledge that they’re not a world of their own; syntactic support for constraint annotation should be available in SQL so it can be done right in the schema. As well, details for errors raised should be available as structured data. Then something vaguely like Data::FormValidator could be built around this. I’m not quite sure of the line where the concerns would be split between database and client code, though. Absent of direct support in SQL, a lot of this might still be achievable with some sort of SQL preprocessor and a wrapper layer over the database, although the at least the wrapper will probably have to be rewritten for each RDBMS.

A great many details need to be thought through, and so far all I have is vague intuitions and ill-defined gut feeling. Maybe all I wrote above is wrong.

The scope of the problem is staggering; I don’t believe I can surmount it on my own. But no one seems to have a particularly avid interest. I am disheartened to find how little work has been done in this area, generally. We’ve been using RDBMS for how long, now? The sorry state of error reporting in that field is actually known well enough. Surely, that would have gotten notice so far. But no, everyone just seems to scrape by with kludges and minimal solutions. I really don’t understand this.

Nevertheless, a sketch of what it all should work like seems feasible, so I occasionally spend time scribbling and mulling.

Makeshifts last the longest.