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 Wed, 27 Jan 2010 00:01:27 GMT
Hello everyone,

I have just submitted my changes that I have made for EMPIREDB-71 (all around auto generated
My goal was primarily to support other type of auto-generated columns rather than the numeric
autoinc type that we currently support.
As an example I have used Mircosoft SQL-Server's uniqueidentifier which can act as a unique
row id (rowguidcol).

To add extra flexiblity I have made several more changes to improve column definition an checking.
The changes are quite substantial.
Here's what I have done:

1. Added a new DataType called UNIQUEID to the DataType enum. Currently this is only supported
by the MSSQL driver. However it should be feasible and fairly simple to make an emulation
that all other databases could use by default for this type. This is a TODO.

2. Added a new enumeration called DataMode. This enum specifies whether a column is readonly,
nullable (optional), not null (required) or auto-generated. This enum type is now used in
the column defintion (see DBTable.addColumn or DBTableColumn constructor) instead of the boolean
Required parameter. The old methods are still supplied for backwards compatibility but should
not be used any more. In order not to mess up complex existing database definition I have
not set the Deprecated annotation on the addColumn function yet. It could be added later (or

The intention is to make the data model defintion more readable (DataMode.NotNull and DataMode.Nullable
and instead of a true and false). 
I am not too happy about the name of the enum (DataMode) but I have been thining and trying
out various alternatives (e.g. Modifier, InsMode etc.) and this is the one I finally ended
up with. Let me know If you have a better idea.

3. There is now a property called isAutoGenerated on the Column interface. As explained to
McKinley checking against the DataType AUTOINC is still required a some point (specifially
in DBRowSet.updateRecord()). The intention is to declare other columns like e.g. the Update-Timestamp
- which is not a row id - as Auto-Generated too. Still however it it necessary to tell Empire-db
which column the timestamp column is.

I have changed the samples to illustrate the new data model definion (see SampleDB and SampleAdvDB).
Hope you all like my changes.


McKinley wrote:
> Re: DataType.AUTOINC Probably Needs a Change
> On Sun, Jan 24, 2010 at 8:18 PM, Rainer Döbele <>
> 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 + "
> > 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

View raw message