http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2204 *** shadow/2204 Wed Jun 20 15:55:23 2001 --- shadow/2204.tmp.8086 Wed Jun 20 18:43:38 2001 *************** *** 127,129 **** --- 127,154 ---- | 0 | +----+ 1 row in set (0.00 sec) + + + ------- Additional Comments From [EMAIL PROTECTED] 2001-06-20 18:43 ------- + I think it's ok to be "tricky" in some cases. But as i understood the intention + of "peers" and the "om", it should be generic, allowing to interact with more + than one DBMS. "Required" columns should never be null. "autoincrement" columns + do have a "initial value" and an "increment" - following the nature of + an "autoincrement" and the expectations of the "user", it should never been + allowed to be "null" in general. + + The "tricky" autoincrement workaround brought in by "dlr" seems not to be + correct to me. I would create the "auto_increment" column using "uniqueness": + create table foo ( id int auto_increment not null, index(id), unique(id)) + + The statement "update foo set id=null" does not really insert a "NULL" into a + field - the DBMS takes care to convert it into "0" (zero) - and WARNS! + + And: Signing columns with attribute "autoincrement" or "required" as proposed + does not affect the "tricky" MySQL access! + + There should be a kind of separation between "modeling / mapping" in general + and "modeling / mapping" towards a specific DBMS. Using a kind + of "<DBType>Column", implementing more specific behaviour towards the DBMS + could be one solution; using configurable properties could be another. More + alternatives? --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
