I am using AUTOINC columns pretty heavily. There is an assumptions made in Empire-db that does not match DBMS implementations. Auto Increment columns in a database are not necessarily of type int.
In Empire-db the type check for AUTOINC usually looks like this: case AUTOINC: case INT: ... where it is considered to be INT or AUTOINC is not mentioned at all in which case the column is checked, set and get against that default. Some of the problems that I have had are that may columns in DBRecord are getting set to Java Integers when they should be Java Long. Also, I had a bug in some code that was applying a Java String to an AUTOINC column which did not parsed and checked to be numeric because there is no AUTOINC check in DBTableColumn.checkValue(). Because AUTOINC is not one actual data type, but really a different column attribute, can we separate it from DataType? The DataType can be set to INT, LONG or even binary and get all the correct behavior already. The checks for DataType.AUTOINC for determing read only fields can just check a different column attribute and not the DataType. The column definition in DBTable.addColumn() can have an overload for the new auto increment definition. Any solution that keeps AUTOINC in DataType will mean complicating DataType which is an enum now or it will mean adding duplicate AUTOINC types for every other type and duplicate case statements that will usually just fall through to the real type. What do you think? Thanks, McKinley
