empire-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From McKinley <mckinley1...@gmail.com>
Subject Re: DataType.AUTOINC Probably Needs a Change
Date Tue, 19 Jan 2010 15:49:16 GMT
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 <mckinley1411@gmail.com> 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 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
>

Mime
View raw message