incubator-empire-db-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Döbele <>
Subject re: DataType.AUTOINC Probably Needs a Change
Date Tue, 19 Jan 2010 21:27:24 GMT
Hi McKinley,

thanks a lot for your suggestions. This is an interesting subject to discuss but I don't think
the solution is that simple.
Generally IMO an autoinc should always be an integer number - by interpreting the word integer
here as "non fractional number" and explicitly not as in the Java type int. 

In the DML part we generally don't need to know the exact type. When obtaining data from the
database the datatype is set by the driver, and when crating records the data type is gernerally
provided by the application.
Internally we should - if conversion is necessary - always treat DataType.AUTOINC as well
as DataType.INTEGER using the Java Type "long". If it is not implmented like that, then it's
a bug that needs to be addressed.

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).

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. 


McKinley wrote:
> Von: McKinley []
> Betreff: Re: DataType.AUTOINC Probably Needs a Change
> I need to create a patch for multiple data type support for auto
> increment for my projects this week and I would like it to be
> acceptable if I submit it to Empire-db. I have now studied the code
> and I think this will be very easy. I recommend the following.
> 1. AUTOINC is mostly used in the database drivers to set the datatype
> to INT or LONG depending on the DBMS. It should stay there for now but
> AUTOINC should be deprecated. Anyone who leaves their columns set to
> AUTOINC will get the existing behavior.
> 2. An autoIncrement boolean member should be added to DBTableColumn
> class along side the "protected DataType type" member.
> 3. isAutoIncrement() and setAutoIncrement() members will be added to
> DBTableColumn.
> 4. The checks for AUTOINC in org.apache.empire.db and above are very
> few. They will be moved to check isAutoIncrement() or autoIncrement
> directly as approriate.
> 5. The drivers that call methods by pass DataType will need to be
> overloaded to accept DBTableColumn. Anyone making use of the DataType
> arguments on the methods directly will get the same results. I don't
> know who might be using those methods outside the driver, but the
> functionality will not change.  The method overloads that accept
> DBColumn will use the access to all column info to check the
> getDataType() and isAutoIncrement() methods. The drivers internally
> will use DBTableColumn arguments on these methods. Anyone who has
> DECIMAL or UNKNOWN (for example,  GUID on SQL Server) for the DataType
> will get auto increment support if isAutoIncrement() resolves to true.
> The check on DataType and isAutoIncrement can intersect properly for
> SQL Server to provide the 'INDENTITY' DDL in the case of int and
> decimal and not specify 'IDENTITY' in the case of uniqueidentifier.
> That way, a column can always state its explicit data type and gain
> all the type checks for that type, but also have the ability to be
> left out of an INSERT statment and gain its new value upon update.
> 6. The DBTableColumn() will be overloaded to accept a autoincrement
> boolean.
> Thoughts?
> Thanks,
> McKinley
> On Mon, Jan 18, 2010 at 3:31 PM, McKinley <>
> wrote:
> > 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
> > 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
> > 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
> >

View raw message