incubator-empire-db-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benjamin Venditti <>
Subject Re: suggestions for improving Thomas' DBGenerataor
Date Mon, 07 Sep 2009 15:13:57 GMT
Hi Rainer & Thomas

i'm currently a little busy as i'm moving to vienna this month, but i 
haven't forgotten DBGenerator ;-) .

I agree with the most of rainer's suggestions:

    1. A database class needs no connection stuff inside. --> So the 
database will get configured via the constuctor.
    2. A empty (for the beginning) in between table class named XXXTable 
(XXX is a userdefined prefix), so the user (developer) may add methods 
    3. Just put the basics to a individual record class, so no 
locking/attribute getters or relationship finders.
    4. The common XXXRecord (XXX is a userdefined prefix) class should 
utilize generics.

I hope i got it right so far.

Thomas, what do you think about these changes?

best regards,

Rainer Döbele schrieb:
> 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
>> New files:
>>     database-configuration.xml
>>     pom.xml
>> thanks in advance
>>     benni
>>     I currently use HSQL for testing. I therefore had to modify all the
>> database meta-data retrieving code in the file
>>     e.g. the line:
>>            ResultSet fkRs = dbMeta.getImportedKeys(schema, null ,
>> tableName);
>>     was changed to:
>>            ResultSet fkRs = dbMeta.getImportedKeys(null, schema,
>> tableName);

View raw message