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" <[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
> >>
