incubator-empire-db-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Francis De Brabandere <>
Subject Re: suggestions for improving Thomas' DBGenerataor
Date Mon, 07 Sep 2009 15:35:19 GMT
Hi all,

Just to let you guys have my support on this generator. I really hope
we can get our current release out and that we can have this generator
as the next big feature for the next release.


On Mon, Sep 7, 2009 at 5:13 PM, Benjamin Venditti<> wrote:
> 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 there.
>   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,
>   benjamin
> 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);

Microsoft gives you windows, Linux gives you the whole house.

View raw message