Mailing-List: contact empire-db-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: empire-db-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <4B1AF4BC.40008@web.de>
Date: Sun, 06 Dec 2009 01:03:08 +0100
From: Benjamin Venditti <benniven@web.de>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: empire-db-dev@incubator.apache.org
Subject: Re: addColumn() but no addTable()
References: <3ab983230912031519w42e553e7r906cc84053cf8686@mail.gmail.com>
In-Reply-To: <3ab983230912031519w42e553e7r906cc84053cf8686@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: benniven@web.de

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.

@ 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.

@ 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.

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 :).

best regard
    benjamin