empire-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Döbele <doeb...@esteam.de>
Subject re: DB codgen next steps
Date Mon, 09 Nov 2009 21:22:08 GMT
Hi Benjamin,

no problem, take your time. We all have job that comes first.
But remember this is a suggestion. Your welcome to bring in your own ideas.

Rainer

benniven@web.de wrote:
> Re: DB codgen next steps
> 
> Hi Rainer,
> 
> thanks für your further explanation. I think i got you right this time.
> I can't work on that right now, but i'll have time at the weekend.
> 
> Regards
> Benjamin
> 
> Rainer Döbele schrieb:
> > 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
> >>>
> >>>
> >>>
> >
> >


Mime
View raw message