Design flaws with insert

[spand]

For inserts Exposed will (for columns with no explicit value) populate all inserts with defaults/null from the Exposed table object and not actually use the one defined in the actual table on the database by leaving out the column in the insert statement.

This has a couple of problems:

• It is impossible to actually perform an INSERT using the database default value. ie. it may not be known or controlled by another team.
• It boils down to a requirement to keep the code in sync with the database but this is at odds with always on services that by definition must have new and old code running on the database at the same time.

A more flexible and less opinionated design would involve:

• Only use .default() and .defaultExpression() for table creation
• Open for simultaneous use of .clientDefault() (and .default()) which then serves as the application default (This is how I always assumed it worked) instead of having .default() act as both table and client insert defaults.
• Not have an implicit default of NULL for nullable columns. This is a requirement for first bullet.

A note is that I am not talking about Exposed Dao but the plain query dsl. Looking at the git history it seems that these defaults were introduced as opinionated defaults for dao which I guess makes much more sense (other than they are still impossible to opt out of). They spilled over into the dsl though which I find problematic since the dsl ought to support all (or atleast standard) sql. I assume the current behaviour can be moved a layer up into the dao code to keep the behavior of dao intact.

I might be willing to do the bulk of the work involved in this but would like to confirm if it would be desirable or not.

Similar issue #345

[darmstrong1]

I agree with the solution proposed by @spand and would like to know if it might be implemented.
I added a comment to #1558 that could also apply to this one.