You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@empire-db.apache.org by Benjamin Venditti <be...@web.de> on 2009/08/21 01:13:02 UTC
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" <be...@web.de>
> To: <em...@incubator.apache.org>
> 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
>>
Re: Re: Code Generator [first insights]
Posted by Thomas Poling <sn...@comcast.net>.
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" <be...@web.de>
To: <em...@incubator.apache.org>;
<em...@incubator.apache.org>
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" <be...@web.de>
>> To: <em...@incubator.apache.org>
>> 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
>>>
>
>
re: Re: Code Generator [first insights]
Posted by Rainer Döbele <do...@esteam.de>.
Hi Benni,
Just a quick explanation of your driver issue:
Since every database has it's very specific properties, there needs to be a separate class with individual properties for every database driver.
There are different solutions on how the application can deal with different drivers and properties. One way e.g. is that the database driver class name and its properties may be provided in the config file, and that the instantiation als well as setting the properties is implemented using reflection. This will make the code completely flexible and allow using new database drivers without any code changes.
E.G:
<database>
<driverClass>org.apache.empire.db.sqlserver.DBDatabaseDriverMSSQL</driverClass>
<driverProperties>
<databaseName>myDatabase</databaseName>
</driverProperties>
</database>
Currently our sample to not do it this way but use a switch statement. This is good if you want to set database specific properties in the code.
To summarize the point: It's a matter of configuration and how the configuration is applied by the application. I don't think we should put any particular configuration logic in the core.
Rainer
Benniven wrote:
> 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" <be...@web.de>
> > To: <em...@incubator.apache.org>
> > 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
> >>