On Tue, Jan 19, 2010 at 9:27 PM, Rainer Döbele <[email protected]> wrote: > But theoretically we could make autoinc an option of the integer type. > But on the other hand I don't like the idea of creating a autoinc property > since it would not make sense for any other data type (at least not as far as > I know).
We'll have to validate AUTOINC as DataType.INT, DataType.DECIMAL and DataType.UNKNOWN for SQL Server alone. Why not just let the definitions for each DataType take care of that validation? I had a real problem with AUTOINC. I passed an AUTOINC column the value from a String getter. I had an unquoted string in my insert statement. This is because there are no validation checks for AUTOINC. Sure it was my bug, but why wasn't I warned? They could be made to match DataType.INT, but why work so hard? Let the DataType checks do there job of validating input. > Long time ago, we decided to make AUTOINC a type of its own, that is in some > way related to the integer type (maybe a bit like char, text and clob). This > was a design descision that was neither right nor wrong - it was the option > that was chosen. > At the moment, I do neither see the requirement nor a benefit in changing > this. > > So - I am sorry to say - but I'd rather leave things as they are. In the DDL for SQL Server alone you cannot specify 'IDENTITY' then. Or, you cannot allow INSERT statements for tables with primary keys of type UNIQUEIDENTIFIER. Those primary keys are "AUTOINC", effectively, but you cannot specify 'INDENTITY' when defining the column in SQL Server. In the place where the DDL is defined in Empire-db the data type AUTOINC isn't enough. You have lost meta data information and you don't have it when you need it. We need to get it from some place. Thanks, McKinley
