On Sun, Jan 24, 2010 at 8:18 PM, Rainer Döbele <[email protected]> wrote: > This code does not work for anything else than the AUTOINC datatype that we > already support as far as I can see. > Or in other words: at the moment it looks that even with such a new property > we would still need to check against the AUTOINC datatype for the above > example. I am surprised that you have not come across this problem yet.
Perhaps ROWGUIDCOL is a bad fit for AUTOINC and should just be treated as something else. It is true that you have to use some other method to get the last inserted key. > Also I am having problems with your case statements example (see below). > The whole idea is that the database driver must be able to decide what the > best (or only) numeric type for AUTOINC columns is, whereas with other > columns the user decides on scale an precision. I doubt that there are any > databases natively supporting anything else than integer (non-fractional) > numbers and it does makes absolutely no sense to limit the number of digits. > Hence I do not agree that AUTOINC is simply INTEGER plus + " IDENTITY". > And since we already have three numeric types INTEGER, DECIMAL and DOUBLE > there is no reason why we should not take on AUTOINC as one of its own as > well. Again: For DDL generation the driver MUST decide on the best type and > for DML it does not matter! I can see your point about having a best default for DDL. I understand your point about DML not mattering but, I disagree slightly. When using a WHERE clause there is a little safety that is forfeited because the AUTOINC column is not run through all the evaluation of INTEGER or DECIMAL. My thought is why repeat those checks for AUTOINC when AUTOINC can just be another check on top of those? And that impacts not just Empire-db. I am now auto generating HTML forms and Javascript pre-validation based on the DBTable and DBColumn meta data in my Empire-db schema classes. I would like to know when my AUTOINC column is one type or another before I use it in a WHERE. > @McKinley: Give me another day or two and I will come up with a suggestion. Thanks so much, McKinley
