Benniven wrote: > Re: addColumn() but no addTable() > > Hi there, > > so currently there are two main issues: > - relations > - handling database specific things > > i'll have a look on the relations soon, as i don't know where to start > with handling the database specific things.
All database specific things should be handled by the driver. So far however there was no need to involve the driver at all. Hence we need to add a config param that allows to specify a DBDatabaseDriver derived class, plus allowing driver specific properties to be set. Then we need to introduce the driver into the parsing process. I have an idea about how to do this but not the time to do it. If you feel you can do it from the above description then please go ahead. Otherwise you'll have to wait until after Christmas (Santa Claus might be able to deliver). > > @ Francis: > >>I think it might be usefull to have addTable() on a DBDatabase. This > makes everything a bit more consistent in my eyes. > > DBDatabase already has "addTable()" but by adding "addTable(String > table)" it would really be more consistent. addTable(String) does not make sense. A long time ago I have thoroughly thought about this and even though I had the same feeling about the consistency I decided to do it like that. Basically there are two options (which you can both use today): 1. myTable = new MyTable(database); Or 2. myTable = new MyTable(); database.addTable(myTable); For the second solution the table class constructor must provide null for the database parameter in the call to the superclass constructor. IMO solution No 1 is shorter and less error prone. Hence I decided to go for this one. With columns it's a different story since they usually don't have their own classes. > > @ Rainer: > I agree to remove the static accessor in the in the generated database, > thus we make it a normal class instead of a singleton. > And about the two generic methods on the generated database class i'm > not sure what to do. There is only two options: 1. Move the code into the DBDatabase class in the core. 2. Forget them. Everyone how needs such methods can add them himself in his individual database class. Personally I think this is not the preferred way to work with Empire-db and hence I would just delete them. > > Splitting the codegen into a writer and a parser almost only using > DBDatabase objects was pretty straight forward. The only problem was > that they don't cover accessor/mutator names but that could be solved > with a additional ParserUtil class. Gladly it was even easier to > implement the nested column classes :). I like the solution very much. It's exactly what I had in mind. Well done. Rainer
