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
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);
