I like the idea you present here Gunnar, the problem I have is specifically applying this to "timestamp generators" which have 5 different semantics that are unique to generated timestamp values (I think):

1. Use the JDK Date as the timestamp and pass that value to the db (no need to read back the value)
2. Execute the DB current_timestamp and pass that back to the db (no need to read back the value)
3. Embed a call to current_timestamp in the INSERT/UPDATE statement (read the value back afterwards)
4. Perform the INSERT w/o refernce to that column assuming default or trigger populates it (read the value back afterwards)
5. Perform the INSERT/UPDATE w/ reference to that column assuming trigger populates it (read the value back afterwards)

I guess the question boils down to whether these cases are generally applicable across any type of generate value. Really 1 and 2 above boil down to the same thing, generating the value in VM and passing it to the database without need to read it back afterwards. The other 3 options boil down to whether to reference the column in the SQL statement and if so what value to pass; in all 3 cases here we need to read back the value generated by the db. So maybe the generic solution here is:

1. Use the generator contract to generate the value. The returned value is the generated value and is passed to the database. No need to read back the value.
2. The annotation names a database function to use. We embed a call to that function into the SQL. After execution of the SQL, we read back the generated value.
3. The annotation assumes that a DEFAULT or trigger generates the value, allowing for the column to be referenced in the SQL or not. After execution of the SQL, we read back the generated value.