empire-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Döbele <doeb...@esteam.de>
Subject re: Re: Code Generator [first insights]
Date Fri, 21 Aug 2009 09:22:45 GMT
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" <benniven@web.de>
> > To: <empire-db-user@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
> >>


Mime
View raw message