incubator-empire-db-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Döbele <doeb...@esteam.de>
Subject re: Code generator
Date Sat, 05 Dec 2009 10:04:14 GMT
Francis De Brabandere wrote:
> Re: Code generator
> 
> Hi all,
> 
> I have been testing with MySQL and the only problem I found was that
> MySQL is case-sensitive. So I had to remove all to uppercase calls.
> 
> And something else. For my part Benjamin has proven his commitment to
> the project. Maybe we can start a vote to let him in?
>

+1

(sorry for not being able to contribute at the moment. Does anyone know how I can clone myself?)

Regards
Rainer
 
> Cheers,
> Francis
> 
> On Sat, Nov 28, 2009 at 11:35 PM, Rainer Döbele <doebele@esteam.de>
> wrote:
> > Hi folks,
> >
> >
> >
> > finally I have found some time to look at the code generator.
> >
> >
> >
> > This time I decided to test with Microsoft SQL Server and I ran
> straight into a problem:
> >
> > Unlike the Oracle driver I had before, I had to supply the schema
> name with the catalog parameter of DatabaseMetaData.getTables().
> >
> > Otherwise it wouldn't find the tables.
> >
> > Looks like DatabaseMetaData.getTables() behaves very database
> specific.
> >
> > Any idea how we can improve this?
> >
> >
> >
> > Another issue is that the driver may create a sequence table to
> handle sequences.
> >
> > There should be a way to ignore this sequence table.
> >
> > I also had a problem with some character case issues on the column
> name.
> >
> > This should work now.
> >
> >
> >
> > Apart from that the general class layout looks good.
> >
> > I only felt the desire to rename the CodeGen class to CodeGenWriter.
> >
> > IMO this makes more sense. Hope nobody minds.
> >
> >
> >
> > The most important thing missing are the relations.
> >
> > I think they should be added next.
> >
> >
> >
> > And I found that we should remove a few things from the generated
> database class.
> >
> > The two generic methods are not specific to the database supplied an
> could go directly in DBDatabase.
> >
> > I am however not sure, whether I really recommend to work this way.
> >
> > This is more like traditional ORM's handle it and it breaks our
> paradigm - although it is not wrong.
> >
> >
> >
> > And the static accessor should go as well. We cannot decide whether
> someone wants one or multiple instances and how they should be
> accessed.
> >
> > It is even likely that someone wants to derived a class from the
> generated database class in order to be able to generate the classes
> again without loosing his modifications.
> >
> > So if nobody objects I will remove this the next time.
> >
> >
> >
> > Long time since we have last heard anything of Thomas Poling.
> >
> > Maybe he has still not subscribed to empire-db-dev that why I put him
> on CC.
> >
> > Thomas if you read this - give us a sign.
> >
> >
> >
> > Benjamin IMO you have done a good job so far.
> >
> > I was surprised that splitting the process up in a parser and a
> writer by only using a DBDatabase object has not been more difficult
> (or was it?).
> >
> > And thanks Francis for checking everything in and fixing those
> "findbugs".
> >
> >
> >
> > So how about doing the relations next?
> >
> > Benjamin are you up for that?
> >
> >
> >
> > Regards
> >
> > Rainer
> >
> >
> >
> >
> 
> 
> 
> --
> http://www.somatik.be
> Microsoft gives you windows, Linux gives you the whole house.

Mime
View raw message