incubator-empire-db-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Francis De Brabandere <franci...@gmail.com>
Subject Re: DB codgen next steps
Date Mon, 09 Nov 2009 07:30:40 GMT
sounds like a good idea to me

On Sun, Nov 8, 2009 at 9:39 PM, Rainer Döbele <doebele@esteam.de> wrote:
> Hi Benni,
>
> I am sorry that I have not been able to respond earlier - job and family have just been
to busy recently.
>
> I am not 100% sure whether you fully understood what I intended to say - so I'll try
again with different words:
> Basically it is that I would perfer - if possible of course - to split the db code generation
into a two step process.
>
> In the first step - the parsing - we obtain the metadata of an existing database and
generate an in-memory object model using the Empire-db classes. Hence the step could be possibly
implemented with a function that takes a connection and some more info (i.e. via the CodeGenConfig
object) and that returns a new DBDabase object which contains all the tables, views, references
etc. The function may look like this:
>
>    public DBDatabase parseDataModel(Connection conn, CodeGenConfig config)
>
> The second step takes provides the functionality to take any DBDatabase object - no matter
whether it's the outcome of the parse process or taken from somewhere else - and generates
the corresponding class files.
> The method for this step could look like this:
>
>    public void generateCodeFiles(DBDatabase db, CodeGenConfig config)
>
> Ideally the objects in org.apache.empire.db.codegen.types would not be required any more.
> The logic we have not in those classes should then all go into one class (possible called
CodeGenParser).
> The aim should also be not to extend the Empire-db core classes just for the generation
process.
> But should this be nessary and there is no other way then I would consider that too.
>
> This would mean quite a new structure of our project - but I believe it would be worth
it.
> Now do you feel you could handle this?
>
> If so, then please feel free to go ahead (unless anyone has got another idea).
> If I can be of any help, please let me know.
>
> Regards
> Rainer
>
>
> benniven@web.de wrote:
>> Re: DB codgen next steps
>>
>> Hi Rainer,
>>
>> I really appreciate that my patch was useful, and I'd like to join up
>> for the next issue.
>>
>> Just a summary about the issues you postet, I'm not sure if I got them
>> right.
>>
>> 1. So the data collection through JDBC will remain in the codegen, but
>> uses already existing classes like DBDatabase, DBTable, DBColumn etc.
>> to
>> set up the class hierarchy. Using the already existing classes instead
>> of another set of beans seems reasonable to me. The actual class file
>> generation will then do the Empire-db database (DBDatabase) itself.
>>
>> QUOTE>> This would then allow to use the class hierarchy directly even
>> without the generation of the class files.<<QUOTE
>>
>> How could the class hierarchy be used without generating them? Of
>> course
>> the hierarchy is already set up in memory, but to access a specific
>> Table object one would have to iterate all tables and find the desired
>> table with a string comparison.
>>
>> In fact I like the idea, that a DBDatabase can replicate itself by
>> writing class files to the filesystem. However I don't see when that
>> could be useful. I'd prefer not to modify any of the existing classes
>> from empire-db core. If we still like to do so, I think it should be
>> done when the codegen is more mature.
>>
>> 2. I am working on HSQL and H2. For testing I used a data model from a
>> university project I was once involved in. Where can I get DBSAMPLE and
>> the DBSAMPLEADV data models from?
>>
>> Please let me know what you think about my comments.
>> Regards
>>     Benjamin
>>
>>
>>
>> Rainer Döbele schrieb:
>> > Hi everyone,
>> >
>> > I have now checked in Benjamin's patch of Oct 26th.
>> > I have changed some bits about the logging and the exclusion of
>> tables containing a '$' in populateTableMetaData() in order to test it
>> with Oracle. Also I had to add one Apache license header in
>> DBUtil.java.
>> >
>> > For our next steps I would like to make the following suggestions:
>> >
>> > 1. At the moment we're parsing metadata obtained via JDBC into
>> generator specific classes (Database, Table, Column) which hold the
>> properties required for the velocity templates. The classes are simple
>> bean type classes.
>> > However wouldn't it be much smarter if the metadata would be parsed
>> directly into an Empire-db class hierarchy i.e. use DBDatabase,
>> DBTable, DBColumn etc.?
>> > This would then allow to use the class hierarchy directly even
>> without the generation of the class files.
>> >
>> > In a second step the class files should then be generated from an
>> Empire-db database (DBDatabase). This step should be independent from
>> step one, so that in theory one could provide the class hierarchy in
>> java and have the same classes generated again.
>>
>> > For properties required for the generation process which are not
>> available in the corresponding Empire-db classes we probably need to
>> provide a helper class or provide them through an extension of the
>> database class.
>> >
>> > 2. Afterwards we should be are able to test and debug it on different
>> database systems. I have currently tested it with the DBSAMPLE data
>> model on Oracle and I can do the same for Microsoft SQL-Server. We
>> should make sure that it works with the DBSAMPLE and DBSAMPLEADV data
>> model on all DBMS that we currently support. All committers please let
>> everyone else know what you are developing and testing with.
>> >
>> > 3. I assume that although JDBC should retrieve metadata in a
>> consistent way there will be aspects that are specific for a certain
>> DBMS (like the exclusion of tables containing a '$' symbol in Oracle).
>> This should be handled by the driver. At the moment however we're not
>> using the Empire-db database drivers and we need to think about how we
>> can let the driver intercept and modify the generation process.
>> >
>> > Suggestion 2 and 3 can wait. Most important for now is suggestion No
>> 1.
>> > Thomas and Benjamin what do you thing about this idea?
>> > Anyone volunteering for getting this done?
>> >
>> > Regards
>> > Rainer
>> >
>> >
>
>



-- 
http://www.somatik.be
Microsoft gives you windows, Linux gives you the whole house.

Mime
View raw message