Greetings Benjamin,
1. I have no locking-columns in my tables. My testing database may be
desinged bad, but i think it can't be assumed that every table has got a
locking column.
As a start and to simplify matters i just commented out everything
that had to do with the locking-columns.
You are correct that the generator should be flexible enough to handle the
case where tables do not have locking columns. For now, I think it would be
easier to alter your tables and add a locking timestamp column. This change
should not affect any legacy use of your tables. This workaround would be
easier than modifying the code.
2. There are some wrong @override annotations, e.g. the "primary key
getter" in "Record.vm" that implements a method instead of overriding it.
I commented out the misplaced annotations.
I never thought of this! Eclipse automatically puts these in when you
implement an interface. Maybe there should be an @Implements annotation. I
think Java 1.6 lets you use this and 1.5 doesn't.
As you recommended i modified the files "Database.java" and the
"Database.vm". I extended its constructor, so that the user has to supply
an instance of the DBDatabaseDriver that shall be used. I tested the
modifications and they seem to work properly.
Thanks for making the improvement.
Unfortunately it looks like, that each different DBDatabaseDriver need a
different setup routine. (check the list of relevant setup properties
below)
So, e.g. if we use MySQL we need to call "setDatabaseName(...)", but if
we use HSQL that function can't be called as it doesn't exist.
Have you got an idea how this could be solved classy?
I don't know if this is a classy solution, but maybe we need to extend the
Database class for each type of database. In the constructor each would
create their DBDatabaseDriver instance and set any properties needed. The
caller would then use, e.g. Database db = new MySqlDatabase(connection
info...)
Thanks, Tom
----- Original Message -----
From: "Benjamin Venditti" <[email protected]>
To: <[email protected]>;
<[email protected]>
Sent: Thursday, August 20, 2009 7:13 PM
Subject: Re: Re: Code Generator [first insights]
Hi Thomas,
i used your fixed files (DbCodeGenerator.java and BaseRecord.vm) and
they worked fine. However, i still got a lot of compilation errors for 2
reasons.
1. I have no locking-columns in my tables. My testing database may be
desinged bad, but i think it can't be assumed that every table has got a
locking column.
As a start and to simplify matters i just commented out everything
that had to do with the locking-columns.
2. There are some wrong @override annotations, e.g. the "primary key
getter" in "Record.vm" that implements a method instead of overriding it.
I commented out the misplaced annotations.
###There is also a hard-coded reference to the DBDatabaseDriverMySQL
class.
### The Database class should be modified so it can adjust to the
database type.
### Any ideas how this could be done?
As you recommended i modified the files "Database.java" and the
"Database.vm". I extended its constructor, so that the user has to supply
an instance of the DBDatabaseDriver that shall be used. I tested the
modifications and they seem to work properly.
Unfortunately it looks like, that each different DBDatabaseDriver need a
different setup routine. (check the list of relevant setup properties
below)
So, e.g. if we use MySQL we need to call "setDatabaseName(...)", but if
we use HSQL that function can't be called as it doesn't exist.
Have you got an idea how this could be solved classy?
---------------SETUP PROPERTIES-------------------
DBDatabaseDriverPostgreSQL
setDatabaseName(String databaseName)
DBDatabaseDriverOracle
-- nothing relevant
DBDatabaseDriverMySQL
setDatabaseName(String databaseName)
DBDatabaseDriverMSSQL
setDatabaseName(String databaseName)
setObjectOwner(String objectOwner) -- could be relevant
DBDatabaseDriverHSql
-- nothing relevant
DBDatabaseDriverH2
setDatabaseName(String databaseName)
DBDatabaseDriverDerby
setDatabaseName(String databaseName)
-------------------------------------
I enclosed the files i modified in the e-mail, so you may have a look at
my changes.
Benjamin
Thomas Poling schrieb:
Greeting All:
Thanks, Benjamin for testing it out. You caught a good error - The
BaseRecord.vm template file had a hard-coded package name. The
attached files should fix that issue. The only change to the
DbCodeGenerator class is to the createBaseRecordClass() method.
As far as the errors associated with get the database meta-data - this
could be a larger issue. It seems the definitions of database
catalogs vs. schemas depends on the database. There is also a
hard-coded reference to the DBDatabaseDriverMySQL class. The Database
class should be modified so it can adjust to the database type. Any
ideas how this could be done?
Thanks, Tom
----- Original Message ----- From: "Benjamin Venditti" <[email protected]>
To: <[email protected]>
Sent: Monday, August 17, 2009 5:03 PM
Subject: Code Generator [first insights]
Hi there,
first of all, many thanks to Thomas Poling" for supplying his code
about the database generator, i'm looking forward to work with it. I
really think this could be a very valuable addition to EmpireDB.
I compiled code generator you supplied and read the documentation and
tried to execute it with a hsql-database some of my fellow students
and i designed 2 years ago. Unfortunately i could not get it running
out of the box. I had to make the following two adjustments in order
to get the classes generated.
CHANGE 1: dbcodegen.db.Database:73
ResultSet tables = dbMeta.getTables(schemaName, null, "", new
String[] {"TABLE"});
changed to:
ResultSet tables = dbMeta.getTables(null, schemaName, null,
new String[] {"TABLE"});
CHANGE 2: dbcodegen.db.Table:161
ResultSet pkRs = dbMeta.getPrimaryKeys(null, schema, tableName);
changed to:
ResultSet pkRs = dbMeta.getPrimaryKeys(schema, null, tableName);
The generated classes contain a lot of compilation errors, as the
templates contain a few imports/references to classes like
"tfmm.persistence.generated.TfmmDatabase".
I'm going to play around with the templates soon and let you know
more about my results.
Benjamin
