Hi Thomas, Hi Benni,
finally I found the time to take a closer look at the DBGenerataor and what you
are doing there looks very promising already.
So far most conversation has been on the empire-db-user mailing list. I would
recommend moving it to the empire-db-dev mailing list. I am not sure, whether
Thomas is subscribed to this list and if he has received Benjamin's last
message (see below).
At the moment the database connection is hard-coded in DbCodeGenerator::main
which is obviously not a good idea but should be easy to fix. Thanks Benni for
mavenizing the project - Thomas are you happy with that?
As far as the generated code is concerned we should first decide what is
absolutely necessary and what are individual extensions that possibly could be
added manually later. I for example do not find the necessity to generate the
interfaces IRecord and IBaseRecord (besides the "I"- prefix is not commonly
used in Java). Once the Record class has been generated e.g. anyone can
manually extend it and generate an interface for the class.
What I would recommend to generate is the following:
- The database class, but only with the definition and without all the
connection stuff. A database may be used in more than one instance with
different connections and thus it's not necessarily a singleton.
- A base table class that goes between DBTable and the actual individual table
classes. The name should be configurable (if it is XXXDatabase it should be
XXXTable). This class can be empty at first so that the user can add methods
there. I always create such an in-between table class in my projects and I use
it for auto-setting fields like user-names or create-timestamps. It's very
convenient.
- The individual table classes, possibly with an option to generate top level
classes (individual files) or to create them as nested classes inside the
database class (if this is possible).
- A base record class as you have done, but the class signature should be as
follows:
public class XXXRecord<T extends XXXTable> extends DBRecord
Using generics here brings a real advantage, as the base record class can
then use properties and methods of the base table class.
- The individual record classes. Personally I don't like and need the access
methods for simple attributes and the finder methods (they make it look like
OR-Mapper beans and people may use them like that). The purpose of these
classes should be mainly to override methods like getFieldOptions, update and
delete.
These are my suggestions. I would appreciate if you would be willing to work
with us any possibly donate your code to the ASF so that we can supply it with
a future release of Empire-db. In this case we could add the code to our svn
repository so that you can all conveniently work on it.
What do you think?
Regards,
Rainer
Benniven wrote:
> re: automatic empire-db driver configuration | mavenizing
>
> Hi there,
>
> i added the code to the Database.vm template so that it can
> automatically configure the desired EmpireDB driver.
> I used jetty's XMLConfiguration class to do that. I also mavenized the
> project, so that it is easier to get it running.
> Please let me know what you think of it.
>
> Modified files:
> Database.vm
> Database.java
> DbCodeGenerator.java
>
> New files:
> database-configuration.xml
> pom.xml
>
> thanks in advance
> benni
>
> WARNING:
> I currently use HSQL for testing. I therefore had to modify all the
> database meta-data retrieving code in the file Table.java.
> e.g. the line:
> ResultSet fkRs = dbMeta.getImportedKeys(schema, null ,
> tableName);
> was changed to:
> ResultSet fkRs = dbMeta.getImportedKeys(null, schema,
> tableName);
