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

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.

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?

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.

DBTable has a addColumn method that does nothing more than calling the
constructor of the column. I think it might be usefull to have
addTable() on a DBDatabase. This makes everything a bit more
consistent in my eyes.

What do you guys think?

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

I'll take care of this one

On Wed, Dec 2, 2009 at 12:32 AM, Benjamin Venditti <benniven@web.de> wrote:
> Hi there,
>
> I have uploaded a small patch that adds the functionality for creating
> nested table classes within the database class, instead of creating separate
> table class files.
>
> The patch contains the following changes:
> modifications:
>  - CodeGenWriter.java
>  - Database.vm
>  - Table.vm
>
> Regards
>  Benjamin
>
>



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

Hi there,

I have uploaded a small patch that adds the functionality for creating 
nested table classes within the database class, instead of creating 
separate table class files.

The patch contains the following changes:
 modifications:
  - CodeGenWriter.java
  - Database.vm
  - Table.vm

Regards
   Benjamin

Hi,

> first I want to welcome your offer to contibute.
> Contribution is always welcome and we're happy to check and
> accept any improvement that brings the project forward.
> Before you start we should talk abut what exactly we want
> to do.
Thanks.

> 1. I have not spend any time investigating myself but what
> makes you so sure that the JDBC-driver will not transmit the
> value supplied by setMaxRows() to the database just like if
> it is specified in the phrase?

Well, theoretically, JDBC can do this, but I have not seen this happen at least with the drivers
I have used before. In fact I have never seen driver to perform self-decided modifications
to SQL query which program supplies.

> 2. If there is a difference, is it worth supporting both
> i.e. limit in the phrase and the limiting the rows using
> setMaxRows() and why whould that make sense?

Yes, I think if we set limit inside Query, we can also setMaxRows(). Seems logical.

> 3. As far as the SQL Phase is concerned we have a solution
> for MySQL. But SQLServer and Oracle (through a rownum
> constraint) AFAIK only support a limit but no offset. Which
> databases do you know support a limit and which support an
> offset in the sql phrase. Please also let us know how? 

Based on SQLAlchemy I can say that MySQL, MSSQL (2005+), PostgreSQL and SQLite support both
LIMIT and OFFSET. Only Oracle has no OFFSET support but seems that it can be simulated with
'ROW NUMBER OVER...' construct.

I will try to make the required change but as I get more acquainted with your code, I see
that current inheritance based design is not much capable of handing so much diversity and
maybe in future there is a need to overhaul in favor of a design similar to dialect in SQLAlchemy's
or Hibernate/JPA.

Regards,
Amin

--- On Mon, 11/30/09, Rainer Döbele <doebele@esteam.de> wrote:

> From: Rainer Döbele <doebele@esteam.de>
> Subject: re: Limit Query Results inside DBCommand
> To: empire-db-dev@incubator.apache.org
> Date: Monday, November 30, 2009, 7:06 PM
> Hi Amin,
> 
> first I want to welcome your offer to contibute.
> Contribution is always welcome and we're happy to check and
> accept any improvement that brings the project forward.
> Before you start we should talk abut what exactly we want
> to do.
> 
> You seem to be really expericend with this problem.
> But I still have a few questions:
> 
> 1. I have not spend any time investigating myself but what
> makes you so sure that the JDBC-driver will not transmit the
> value supplied by setMaxRows() to the database just like if
> it is specified in the phrase?
> 
> 2. If there is a difference, is it worth supporting both
> i.e. limit in the phrase and the limiting the rows using
> setMaxRows() and why whould that make sense?
> 
> 3. Als far as the SQL Phase is concerned we have a solution
> for MySQL. But SQLServer and Oracle (through a rownum
> constraint) AFAIK only support a limit but no offset. Which
> databases do you know support a limit and which support an
> offset in the sql phrase. Please also let us know how? 
> 
> Regards
> Rainer
> 
> 
> Amin Abbaspour wrote:
> > re: Limit Query Results inside DBCommand
> > 
> > Dear Rainer,
> > 
> > JDBC setMaxRows is not equivalent to SQL LIMIT from
> the database's
> > point of view. setMaxRows sets the max number of rows
> ResultSet can
> > contain and AFAIK ResultSet ignores the results more
> that that limit,
> > while SQL LIMIT informs database engine about the
> count of the rows
> > client wants hence engine does not perform more work
> as soon as it gets
> > to requested number of rows.
> > 
> > As Francis mentioned, pagination is important too.
> This is particularly
> > useful when we have paged view (e.g. LOV pattern).
> > 
> > Besides limit and pagination which is occasionally
> required based on
> > application logic, limiting has tangible performance
> results in some
> > databases engines such as DB2, hence its always said
> that one would
> > better append a 'FETCH FIRST n ROWS ONLY' if he is
> sure his query has a
> > clause that will return only N row(s).
> > 
> > I personally don't see much problem in implementing
> this. If you want,
> > I can do it and sent diff files.
> > 
> > BTW I also want to add some LOCKING feature to
> SQLServer SELECT but
> > would like to know your point of view to see how to
> implement that we
> > both preserver polymorphism/OOP and database specific
> features.
> > 
> > Regards,
> > Amin
> > 
> > --- On Sun, 11/29/09, Rainer Döbele <doebele@esteam.de>
> wrote:
> > 
> > > From: Rainer Döbele <doebele@esteam.de>
> > > Subject: re: Limit Query Results inside
> DBCommand
> > > To: empire-db-dev@incubator.apache.org
> > > Date: Sunday, November 29, 2009, 11:47 PM
> > > Francis De Brabandere wrote:
> > > > Re: Limit Query Results inside DBCommand
> > > >
> > > > you might also want to implement paging,
> added a
> > > comment tot the issue
> > >
> > > Not sure whether we should to do this.
> > > If we solve it using the setMaxRows() on the
> statement,
> > > which is what I prefer, then there does not seem
> to be a way
> > > to specify an offset.
> > >
> > > At the moment I cannot see a solution for the
> paging that
> > > will work for all databases.
> > > If this is a special feature of MySql then we can
> provide
> > > it as a particular extension for MySql (just like
> the
> > > connectByPrior that we support for Oracle).
> > >
> > > Rainer
> > >
> > > >
> > > > On Sun, Nov 29, 2009 at 1:25 PM, Rainer
> Döbele <doebele@esteam.de>
> > > > wrote:
> > > > > Hi Amin,
> > > > >
> > > > > unfortunately I must confess that we
> currently
> > > don't have the ability
> > > > to limit the number of rows returned.
> > > > >
> > > > > This shows how different people work
> with
> > > databases.
> > > > > In my many years of database
> programming I have
> > > never really felt the
> > > > need for it since I always found a
> constraint to work
> > > with.
> > > > > I only sometimes use it for interactive
> queries
> > > to the database.
> > > > > But you are right, this is a thing we
> definitely
> > > have to add.
> > > > >
> > > > > I have created a JIRA issue for that
> and I will
> > > implement that ASAP.
> > > > > Unfortunately this feature is handled
> differently
> > > by each database.
> > > > > e.g.
> > > > > SQL Server:
> > > > > SELECT TOP 10 id, name, ...
> > > > > FROM contacts
> > > > >
> > > > > MySQL:
> > > > > SELECT id, name, ...
> > > > > FROM contacts
> > > > > LIMIT 10
> > > > >
> > > > > ORACLE:
> > > > > SELECT id, name, ...
> > > > > FROM contacts
> > > > > WHERE ROWNUM <= 10
> > > > >
> > > > > Another option is to use setMaxRows()
> before
> > > executing the statement.
> > > > > This looks like a better idea to me
> since the
> > > JDBC driver can handle
> > > > it.
> > > > > Does anyone know if this is really
> equivalent?
> > > > >
> > > > > Rainer
> > > > >
> > > > >
> > > > > Amin Abbaspour wrote:
> > > > >> re: Limit Query Results inside
> DBCommand
> > > > >>
> > > > >> Hello to everyone,
> > > > >>
> > > > >> This is my first email in
> empire-db's users
> > > list :)
> > > > >>
> > > > >> One small question; How can I limit
> the
> > > number of rows returned in
> > > > >> select statements (i.e. SELECT ....
> LIMIT x,
> > > or SELECT TOP x ...)?
> > > > >>
> > > > >> Right now I do this manually by
> appending a
> > > "LIMIT x" to my query's
> > > > >> string but this is such a frequent
> > > requirement that I am pretty sure
> > > > >> this is implemented but I failed to
> find it.
> > > > >>
> > > > >> Regards,
> > > > >> Amin Abbaspour
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > http://www.somatik.be
> > > > Microsoft gives you windows, Linux gives you
> the whole
> > > house.
> > >
> > 
> > 
> > 
> 


      

Hi Amin,

first I want to welcome your offer to contibute.
Contribution is always welcome and we're happy to check and accept any improvement that brings
the project forward.
Before you start we should talk abut what exactly we want to do.

You seem to be really expericend with this problem.
But I still have a few questions:

1. I have not spend any time investigating myself but what makes you so sure that the JDBC-driver
will not transmit the value supplied by setMaxRows() to the database just like if it is specified
in the phrase?

2. If there is a difference, is it worth supporting both i.e. limit in the phrase and the
limiting the rows using setMaxRows() and why whould that make sense?

3. Als far as the SQL Phase is concerned we have a solution for MySQL. But SQLServer and Oracle
(through a rownum constraint) AFAIK only support a limit but no offset. Which databases do
you know support a limit and which support an offset in the sql phrase. Please also let us
know how? 

Regards
Rainer


Amin Abbaspour wrote:
> re: Limit Query Results inside DBCommand
> 
> Dear Rainer,
> 
> JDBC setMaxRows is not equivalent to SQL LIMIT from the database's
> point of view. setMaxRows sets the max number of rows ResultSet can
> contain and AFAIK ResultSet ignores the results more that that limit,
> while SQL LIMIT informs database engine about the count of the rows
> client wants hence engine does not perform more work as soon as it gets
> to requested number of rows.
> 
> As Francis mentioned, pagination is important too. This is particularly
> useful when we have paged view (e.g. LOV pattern).
> 
> Besides limit and pagination which is occasionally required based on
> application logic, limiting has tangible performance results in some
> databases engines such as DB2, hence its always said that one would
> better append a 'FETCH FIRST n ROWS ONLY' if he is sure his query has a
> clause that will return only N row(s).
> 
> I personally don't see much problem in implementing this. If you want,
> I can do it and sent diff files.
> 
> BTW I also want to add some LOCKING feature to SQLServer SELECT but
> would like to know your point of view to see how to implement that we
> both preserver polymorphism/OOP and database specific features.
> 
> Regards,
> Amin
> 
> --- On Sun, 11/29/09, Rainer Döbele <doebele@esteam.de> wrote:
> 
> > From: Rainer Döbele <doebele@esteam.de>
> > Subject: re: Limit Query Results inside DBCommand
> > To: empire-db-dev@incubator.apache.org
> > Date: Sunday, November 29, 2009, 11:47 PM
> > Francis De Brabandere wrote:
> > > Re: Limit Query Results inside DBCommand
> > >
> > > you might also want to implement paging, added a
> > comment tot the issue
> >
> > Not sure whether we should to do this.
> > If we solve it using the setMaxRows() on the statement,
> > which is what I prefer, then there does not seem to be a way
> > to specify an offset.
> >
> > At the moment I cannot see a solution for the paging that
> > will work for all databases.
> > If this is a special feature of MySql then we can provide
> > it as a particular extension for MySql (just like the
> > connectByPrior that we support for Oracle).
> >
> > Rainer
> >
> > >
> > > On Sun, Nov 29, 2009 at 1:25 PM, Rainer Döbele <doebele@esteam.de>
> > > wrote:
> > > > Hi Amin,
> > > >
> > > > unfortunately I must confess that we currently
> > don't have the ability
> > > to limit the number of rows returned.
> > > >
> > > > This shows how different people work with
> > databases.
> > > > In my many years of database programming I have
> > never really felt the
> > > need for it since I always found a constraint to work
> > with.
> > > > I only sometimes use it for interactive queries
> > to the database.
> > > > But you are right, this is a thing we definitely
> > have to add.
> > > >
> > > > I have created a JIRA issue for that and I will
> > implement that ASAP.
> > > > Unfortunately this feature is handled differently
> > by each database.
> > > > e.g.
> > > > SQL Server:
> > > > SELECT TOP 10 id, name, ...
> > > > FROM contacts
> > > >
> > > > MySQL:
> > > > SELECT id, name, ...
> > > > FROM contacts
> > > > LIMIT 10
> > > >
> > > > ORACLE:
> > > > SELECT id, name, ...
> > > > FROM contacts
> > > > WHERE ROWNUM <= 10
> > > >
> > > > Another option is to use setMaxRows() before
> > executing the statement.
> > > > This looks like a better idea to me since the
> > JDBC driver can handle
> > > it.
> > > > Does anyone know if this is really equivalent?
> > > >
> > > > Rainer
> > > >
> > > >
> > > > Amin Abbaspour wrote:
> > > >> re: Limit Query Results inside DBCommand
> > > >>
> > > >> Hello to everyone,
> > > >>
> > > >> This is my first email in empire-db's users
> > list :)
> > > >>
> > > >> One small question; How can I limit the
> > number of rows returned in
> > > >> select statements (i.e. SELECT .... LIMIT x,
> > or SELECT TOP x ...)?
> > > >>
> > > >> Right now I do this manually by appending a
> > "LIMIT x" to my query's
> > > >> string but this is such a frequent
> > requirement that I am pretty sure
> > > >> this is implemented but I failed to find it.
> > > >>
> > > >> Regards,
> > > >> Amin Abbaspour
> > > >>
> > > >>
> > > >>
> > > >>
> > > >
> > >
> > >
> > >
> > > --
> > > http://www.somatik.be
> > > Microsoft gives you windows, Linux gives you the whole
> > house.
> >
> 
> 
> 

Dear Rainer,

JDBC setMaxRows is not equivalent to SQL LIMIT from the database's point of view. setMaxRows
sets the max number of rows ResultSet can contain and AFAIK ResultSet ignores the results
more that that limit, while SQL LIMIT informs database engine about the count of the rows
client wants hence engine does not perform more work as soon as it gets to requested number
of rows.

As Francis mentioned, pagination is important too. This is particularly useful when we have
paged view (e.g. LOV pattern).

Besides limit and pagination which is occasionally required based on application logic, limiting
has tangible performance results in some databases engines such as DB2, hence its always said
that one would better append a 'FETCH FIRST n ROWS ONLY' if he is sure his query has a clause
that will return only N row(s).

I personally don't see much problem in implementing this. If you want, I can do it and sent
diff files.

BTW I also want to add some LOCKING feature to SQLServer SELECT but would like to know your
point of view to see how to implement that we both preserver polymorphism/OOP and database
specific features. 

Regards,
Amin

--- On Sun, 11/29/09, Rainer Döbele <doebele@esteam.de> wrote:

> From: Rainer Döbele <doebele@esteam.de>
> Subject: re: Limit Query Results inside DBCommand
> To: empire-db-dev@incubator.apache.org
> Date: Sunday, November 29, 2009, 11:47 PM
> Francis De Brabandere wrote:
> > Re: Limit Query Results inside DBCommand
> > 
> > you might also want to implement paging, added a
> comment tot the issue
> 
> Not sure whether we should to do this.
> If we solve it using the setMaxRows() on the statement,
> which is what I prefer, then there does not seem to be a way
> to specify an offset.
> 
> At the moment I cannot see a solution for the paging that
> will work for all databases.
> If this is a special feature of MySql then we can provide
> it as a particular extension for MySql (just like the
> connectByPrior that we support for Oracle).
> 
> Rainer
> 
> > 
> > On Sun, Nov 29, 2009 at 1:25 PM, Rainer Döbele <doebele@esteam.de>
> > wrote:
> > > Hi Amin,
> > >
> > > unfortunately I must confess that we currently
> don't have the ability
> > to limit the number of rows returned.
> > >
> > > This shows how different people work with
> databases.
> > > In my many years of database programming I have
> never really felt the
> > need for it since I always found a constraint to work
> with.
> > > I only sometimes use it for interactive queries
> to the database.
> > > But you are right, this is a thing we definitely
> have to add.
> > >
> > > I have created a JIRA issue for that and I will
> implement that ASAP.
> > > Unfortunately this feature is handled differently
> by each database.
> > > e.g.
> > > SQL Server:
> > > SELECT TOP 10 id, name, ...
> > > FROM contacts
> > >
> > > MySQL:
> > > SELECT id, name, ...
> > > FROM contacts
> > > LIMIT 10
> > >
> > > ORACLE:
> > > SELECT id, name, ...
> > > FROM contacts
> > > WHERE ROWNUM <= 10
> > >
> > > Another option is to use setMaxRows() before
> executing the statement.
> > > This looks like a better idea to me since the
> JDBC driver can handle
> > it.
> > > Does anyone know if this is really equivalent?
> > >
> > > Rainer
> > >
> > >
> > > Amin Abbaspour wrote:
> > >> re: Limit Query Results inside DBCommand
> > >>
> > >> Hello to everyone,
> > >>
> > >> This is my first email in empire-db's users
> list :)
> > >>
> > >> One small question; How can I limit the
> number of rows returned in
> > >> select statements (i.e. SELECT .... LIMIT x,
> or SELECT TOP x ...)?
> > >>
> > >> Right now I do this manually by appending a
> "LIMIT x" to my query's
> > >> string but this is such a frequent
> requirement that I am pretty sure
> > >> this is implemented but I failed to find it.
> > >>
> > >> Regards,
> > >> Amin Abbaspour
> > >>
> > >>
> > >>
> > >>
> > >
> > 
> > 
> > 
> > --
> > http://www.somatik.be
> > Microsoft gives you windows, Linux gives you the whole
> house.
> 


      

Francis De Brabandere wrote:
> Re: Limit Query Results inside DBCommand
> 
> you might also want to implement paging, added a comment tot the issue

Not sure whether we should to do this.
If we solve it using the setMaxRows() on the statement, which is what I prefer, then there
does not seem to be a way to specify an offset.

At the moment I cannot see a solution for the paging that will work for all databases.
If this is a special feature of MySql then we can provide it as a particular extension for
MySql (just like the connectByPrior that we support for Oracle).

Rainer

> 
> On Sun, Nov 29, 2009 at 1:25 PM, Rainer Döbele <doebele@esteam.de>
> wrote:
> > Hi Amin,
> >
> > unfortunately I must confess that we currently don't have the ability
> to limit the number of rows returned.
> >
> > This shows how different people work with databases.
> > In my many years of database programming I have never really felt the
> need for it since I always found a constraint to work with.
> > I only sometimes use it for interactive queries to the database.
> > But you are right, this is a thing we definitely have to add.
> >
> > I have created a JIRA issue for that and I will implement that ASAP.
> > Unfortunately this feature is handled differently by each database.
> > e.g.
> > SQL Server:
> > SELECT TOP 10 id, name, ...
> > FROM contacts
> >
> > MySQL:
> > SELECT id, name, ...
> > FROM contacts
> > LIMIT 10
> >
> > ORACLE:
> > SELECT id, name, ...
> > FROM contacts
> > WHERE ROWNUM <= 10
> >
> > Another option is to use setMaxRows() before executing the statement.
> > This looks like a better idea to me since the JDBC driver can handle
> it.
> > Does anyone know if this is really equivalent?
> >
> > Rainer
> >
> >
> > Amin Abbaspour wrote:
> >> re: Limit Query Results inside DBCommand
> >>
> >> Hello to everyone,
> >>
> >> This is my first email in empire-db's users list :)
> >>
> >> One small question; How can I limit the number of rows returned in
> >> select statements (i.e. SELECT .... LIMIT x, or SELECT TOP x ...)?
> >>
> >> Right now I do this manually by appending a "LIMIT x" to my query's
> >> string but this is such a frequent requirement that I am pretty sure
> >> this is implemented but I failed to find it.
> >>
> >> Regards,
> >> Amin Abbaspour
> >>
> >>
> >>
> >>
> >
> 
> 
> 
> --
> http://www.somatik.be
> Microsoft gives you windows, Linux gives you the whole house.

you might also want to implement paging, added a comment tot the issue

On Sun, Nov 29, 2009 at 1:25 PM, Rainer Döbele <doebele@esteam.de> wrote:
> Hi Amin,
>
> unfortunately I must confess that we currently don't have the ability to limit the number
of rows returned.
>
> This shows how different people work with databases.
> In my many years of database programming I have never really felt the need for it since
I always found a constraint to work with.
> I only sometimes use it for interactive queries to the database.
> But you are right, this is a thing we definitely have to add.
>
> I have created a JIRA issue for that and I will implement that ASAP.
> Unfortunately this feature is handled differently by each database.
> e.g.
> SQL Server:
> SELECT TOP 10 id, name, ...
> FROM contacts
>
> MySQL:
> SELECT id, name, ...
> FROM contacts
> LIMIT 10
>
> ORACLE:
> SELECT id, name, ...
> FROM contacts
> WHERE ROWNUM <= 10
>
> Another option is to use setMaxRows() before executing the statement.
> This looks like a better idea to me since the JDBC driver can handle it.
> Does anyone know if this is really equivalent?
>
> Rainer
>
>
> Amin Abbaspour wrote:
>> re: Limit Query Results inside DBCommand
>>
>> Hello to everyone,
>>
>> This is my first email in empire-db's users list :)
>>
>> One small question; How can I limit the number of rows returned in
>> select statements (i.e. SELECT .... LIMIT x, or SELECT TOP x ...)?
>>
>> Right now I do this manually by appending a "LIMIT x" to my query's
>> string but this is such a frequent requirement that I am pretty sure
>> this is implemented but I failed to find it.
>>
>> Regards,
>> Amin Abbaspour
>>
>>
>>
>>
>



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

Hi Amin,

these functions are provided for convenience only and are indeed intended for small result
sets.
For special needs people can implement their own function - in fact they should use a DBReader.

But what we could easily do, is to provide an overload for those functions that allow to supply
the collection. Hence the use can decide which collection to use.
I will create an JIRA issue for this too.

Thanks again
Rainer


Amin Abbaspour wrote:
> re: Why ArrayList with Unknown Result Count?
> 
> Hello everyone,
> 
> This is my first email in empire-db's developers mailing list :) First
> of all thanks for your ideas and attempts.
> 
> I was reading source code and noticed that ArrayList is used to store
> results in querySimpleList and queryObjectList and also to hold values
> in tables, relations, and views.
> 
> While the second usage (for tables, relations, etc) is not much
> critical since they are limited in size, IMHO using ArrayList without
> initial size is prohibited for large datasets such as those returned by
> queries. As you all know this will result in many times memory
> allocation and collection since it goes from size 10 -> 20 -> 40 ->
> etc.
> 
> I recommend that in the cases that there is a known return value count
> (like selectSingle or select with Limit value), ArrayList should be
> used with initial size in constructor; otherwise LinkedList is a better
> choice.
> 
> Regards,
> Amin Abbaspour
> 
> 
> 
> 

Hi Amin,

unfortunately I must confess that we currently don't have the ability to limit the number
of rows returned.

This shows how different people work with databases. 
In my many years of database programming I have never really felt the need for it since I
always found a constraint to work with.
I only sometimes use it for interactive queries to the database.
But you are right, this is a thing we definitely have to add.

I have created a JIRA issue for that and I will implement that ASAP.
Unfortunately this feature is handled differently by each database. 
e.g.
SQL Server:
SELECT TOP 10 id, name, ...
FROM contacts

MySQL:
SELECT id, name, ...
FROM contacts
LIMIT 10

ORACLE:
SELECT id, name, ...
FROM contacts
WHERE ROWNUM <= 10

Another option is to use setMaxRows() before executing the statement.
This looks like a better idea to me since the JDBC driver can handle it.
Does anyone know if this is really equivalent?

Rainer


Amin Abbaspour wrote:
> re: Limit Query Results inside DBCommand
> 
> Hello to everyone,
> 
> This is my first email in empire-db's users list :)
> 
> One small question; How can I limit the number of rows returned in
> select statements (i.e. SELECT .... LIMIT x, or SELECT TOP x ...)?
> 
> Right now I do this manually by appending a "LIMIT x" to my query's
> string but this is such a frequent requirement that I am pretty sure
> this is implemented but I failed to find it.
> 
> Regards,
> Amin Abbaspour
> 
> 
> 
> 

Hello everyone,

This is my first email in empire-db's developers mailing list :) First of all thanks for your
ideas and attempts.

I was reading source code and noticed that ArrayList is used to store results in querySimpleList
and queryObjectList and also to hold values in tables, relations, and views.

While the second usage (for tables, relations, etc) is not much critical since they are limited
in size, IMHO using ArrayList without initial size is prohibited for large datasets such as
those returned by queries. As you all know this will result in many times memory allocation
and collection since it goes from size 10 -> 20 -> 40 -> etc.

I recommend that in the cases that there is a known return value count (like selectSingle
or select with Limit value), ArrayList should be used with initial size in constructor; otherwise
LinkedList is a better choice.

Regards,
Amin Abbaspour



      

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

 

ok, fixing on the fly from devoxx is not the way to work...

I'll tackle those this evening.

Cheers,
Francis

On Thu, Nov 19, 2009 at 4:35 PM, Apache Hudson Server
<hudson@hudson.zones.apache.org> wrote:
> See <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/86/changes>
>
> Changes:
>
> [francisdb] added fixme on the log file issue
>
> [francisdb] ignore log files for rat check
>
> ------------------------------------------
> [...truncated 2832 lines...]
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-codegen/target/apidocs/org/apache/empire/db/codegen//CodeGen.html...>
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-codegen/target/apidocs/org/apache/empire/db/codegen//CodeGenApp.html...>
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-codegen/target/apidocs/org/apache/empire/db/codegen//CodeGenConfig.html...>
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-codegen/target/apidocs/org/apache/empire/db/codegen//CodeGenParser.html...>
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-codegen/target/apidocs/org/apache/empire/db/codegen//CodeGenParser.InMemoryDatabase.html...>
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-codegen/target/apidocs/org/apache/empire/db/codegen/util//DBUtil.html...>
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-codegen/target/apidocs/org/apache/empire/db/codegen/util//FileUtils.html...>
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-codegen/target/apidocs/org/apache/empire/db/codegen/util//ParserUtil.html...>
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-codegen/target/apidocs/overview-frame.html...>
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-codegen/target/apidocs/org/apache/empire/db/codegen//package-frame.html...>
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-codegen/target/apidocs/org/apache/empire/db/codegen//package-summary.html...>
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-codegen/target/apidocs/org/apache/empire/db/codegen//package-tree.html...>
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-codegen/target/apidocs/org/apache/empire/db/codegen/util//package-frame.html...>
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-codegen/target/apidocs/org/apache/empire/db/codegen/util//package-summary.html...>
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-codegen/target/apidocs/org/apache/empire/db/codegen/util//package-tree.html...>
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-codegen/target/apidocs/constant-values.html...>
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-codegen/target/apidocs/org/apache/empire/db/codegen/class-use//CodeGen.html...>
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-codegen/target/apidocs/org/apache/empire/db/codegen/class-use//CodeGenConfig.html...>
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-codegen/target/apidocs/org/apache/empire/db/codegen/class-use//CodeGenApp.html...>
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-codegen/target/apidocs/org/apache/empire/db/codegen/class-use//CodeGenParser.html...>
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-codegen/target/apidocs/org/apache/empire/db/codegen/class-use//CodeGenParser.InMemoryDatabase.html...>
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-codegen/target/apidocs/org/apache/empire/db/codegen/util/class-use//ParserUtil.html...>
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-codegen/target/apidocs/org/apache/empire/db/codegen/util/class-use//FileUtils.html...>
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-codegen/target/apidocs/org/apache/empire/db/codegen/util/class-use//DBUtil.html...>
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-codegen/target/apidocs/org/apache/empire/db/codegen//package-use.html...>
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-codegen/target/apidocs/org/apache/empire/db/codegen/util//package-use.html...>
> Building index for all the packages and classes...
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-codegen/target/apidocs/overview-tree.html...>
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-codegen/target/apidocs/index-all.html...>
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-codegen/target/apidocs/deprecated-list.html...>
> Building index for all classes...
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-codegen/target/apidocs/allclasses-frame.html...>
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-codegen/target/apidocs/allclasses-noframe.html...>
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-codegen/target/apidocs/index.html...>
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-codegen/target/apidocs/overview-summary.html...>
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-codegen/target/apidocs/help-doc.html...>
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-codegen/target/apidocs/stylesheet.css...>
> [INFO] Building jar: <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-codegen/target/empire-db-codegen-2.0.6-incubating-SNAPSHOT-javadoc.jar>
> [INFO] [license:check {execution: default}]
> [INFO] Checking licenses...
> [INFO] [rat:check {execution: default}]
> [INFO] [install:install {execution: default-install}]
> [INFO] Installing <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-codegen/target/empire-db-codegen-2.0.6-incubating-SNAPSHOT.jar>
to /home/hudson/.m2/repository/org/apache/empire-db/empire-db-codegen/2.0.6-incubating-SNAPSHOT/empire-db-codegen-2.0.6-incubating-SNAPSHOT.jar
> [INFO] Installing <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-codegen/target/empire-db-codegen-2.0.6-incubating-SNAPSHOT-sources.jar>
to /home/hudson/.m2/repository/org/apache/empire-db/empire-db-codegen/2.0.6-incubating-SNAPSHOT/empire-db-codegen-2.0.6-incubating-SNAPSHOT-sources.jar
> [INFO] Installing <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-codegen/target/empire-db-codegen-2.0.6-incubating-SNAPSHOT-javadoc.jar>
to /home/hudson/.m2/repository/org/apache/empire-db/empire-db-codegen/2.0.6-incubating-SNAPSHOT/empire-db-codegen-2.0.6-incubating-SNAPSHOT-javadoc.jar
> [INFO] Installing <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-codegen/target/empire-db-codegen-2.0.6-incubating-SNAPSHOT-sources.jar>
to /home/hudson/.m2/repository/org/apache/empire-db/empire-db-codegen/2.0.6-incubating-SNAPSHOT/empire-db-codegen-2.0.6-incubating-SNAPSHOT-sources.jar
> [INFO] Installing <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-codegen/target/empire-db-codegen-2.0.6-incubating-SNAPSHOT-javadoc.jar>
to /home/hudson/.m2/repository/org/apache/empire-db/empire-db-codegen/2.0.6-incubating-SNAPSHOT/empire-db-codegen-2.0.6-incubating-SNAPSHOT-javadoc.jar
> [INFO] [deploy:deploy {execution: default-deploy}]
> [INFO] Retrieving previous build number from apache.snapshots.https
> Uploading: https://repository.apache.org/content/repositories/snapshots/org/apache/empire-db/empire-db-codegen/2.0.6-incubating-SNAPSHOT/empire-db-codegen-2.0.6-incubating-20091119.153426-13.jar
> 4/30K
> 8/30K
> 12/30K
> 16/30K
> 20/30K
> 24/30K
> 28/30K
> 30/30K
> 30K uploaded  (empire-db-codegen-2.0.6-incubating-20091119.153426-13.jar)
> [INFO] Retrieving previous metadata from apache.snapshots.https
> [INFO] Uploading repository metadata for: 'snapshot org.apache.empire-db:empire-db-codegen:2.0.6-incubating-SNAPSHOT'
> [INFO] Retrieving previous metadata from apache.snapshots.https
> [INFO] Uploading repository metadata for: 'artifact org.apache.empire-db:empire-db-codegen'
> [INFO] Uploading project information for empire-db-codegen 2.0.6-incubating-20091119.153426-13
> [INFO] Retrieving previous build number from apache.snapshots.https
> Uploading: https://repository.apache.org/content/repositories/snapshots/org/apache/empire-db/empire-db-codegen/2.0.6-incubating-SNAPSHOT/empire-db-codegen-2.0.6-incubating-20091119.153426-13-sources.jar
> 4/25K
> 8/25K
> 12/25K
> 16/25K
> 20/25K
> 24/25K
> 25/25K
> 25K uploaded  (empire-db-codegen-2.0.6-incubating-20091119.153426-13-sources.jar)
> [INFO] Retrieving previous build number from apache.snapshots.https
> Uploading: https://repository.apache.org/content/repositories/snapshots/org/apache/empire-db/empire-db-codegen/2.0.6-incubating-SNAPSHOT/empire-db-codegen-2.0.6-incubating-20091119.153426-13-javadoc.jar
> 4/70K
> 8/70K
> 12/70K
> 16/70K
> 20/70K
> 24/70K
> 28/70K
> 32/70K
> 36/70K
> 40/70K
> 44/70K
> 48/70K
> 52/70K
> 56/70K
> 60/70K
> 64/70K
> 68/70K
> 70/70K
> 70K uploaded  (empire-db-codegen-2.0.6-incubating-20091119.153426-13-javadoc.jar)
> [INFO] Retrieving previous build number from apache.snapshots.https
> Uploading: https://repository.apache.org/content/repositories/snapshots/org/apache/empire-db/empire-db-codegen/2.0.6-incubating-SNAPSHOT/empire-db-codegen-2.0.6-incubating-20091119.153426-13-sources.jar
> 4/25K
> 8/25K
> 12/25K
> 16/25K
> 20/25K
> 24/25K
> 25/25K
> 25K uploaded  (empire-db-codegen-2.0.6-incubating-20091119.153426-13-sources.jar)
> [INFO] Retrieving previous build number from apache.snapshots.https
> Uploading: https://repository.apache.org/content/repositories/snapshots/org/apache/empire-db/empire-db-codegen/2.0.6-incubating-SNAPSHOT/empire-db-codegen-2.0.6-incubating-20091119.153426-13-javadoc.jar
> 4/70K
> 8/70K
> 12/70K
> 16/70K
> 20/70K
> 24/70K
> 28/70K
> 32/70K
> 36/70K
> 40/70K
> 44/70K
> 48/70K
> 52/70K
> 56/70K
> 60/70K
> 64/70K
> 68/70K
> 70/70K
> 70K uploaded  (empire-db-codegen-2.0.6-incubating-20091119.153426-13-javadoc.jar)
> [INFO] ------------------------------------------------------------------------
> [INFO] Building Apache Empire-db Examples
> [INFO]    task-segment: [clean, install, deploy]
> [INFO] ------------------------------------------------------------------------
> [INFO] [clean:clean {execution: default-clean}]
> [INFO] Deleting file set: <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-examples/target>
(included: [**], excluded: [])
> [INFO] [enforcer:enforce {execution: enforce-versions}]
> [INFO] [remote-resources:process {execution: default}]
> [INFO] [site:attach-descriptor {execution: default-attach-descriptor}]
> [INFO] Preparing source:jar
> [WARNING] Removing: jar from forked lifecycle, to prevent recursive invocation.
> [INFO] [enforcer:enforce {execution: enforce-versions}]
> [INFO] [source:jar {execution: attach-sources}]
> [INFO] [javadoc:jar {execution: attach-javadocs}]
> [INFO] Not executing Javadoc as the project is not a Java classpath-capable package
> [INFO] [license:check {execution: default}]
> [INFO] Checking licenses...
> [INFO] [rat:check {execution: default}]
> [INFO] [install:install {execution: default-install}]
> [INFO] Installing <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-examples/pom.xml>
to /home/hudson/.m2/repository/org/apache/empire-db/empire-db-examples/2.0.6-incubating-SNAPSHOT/empire-db-examples-2.0.6-incubating-SNAPSHOT.pom
> [INFO] [enforcer:enforce {execution: enforce-versions}]
> [INFO] [remote-resources:process {execution: default}]
> [INFO] [site:attach-descriptor {execution: default-attach-descriptor}]
> [INFO] Preparing source:jar
> [WARNING] Removing: jar from forked lifecycle, to prevent recursive invocation.
> [INFO] [enforcer:enforce {execution: enforce-versions}]
> [INFO] [source:jar {execution: attach-sources}]
> [INFO] [javadoc:jar {execution: attach-javadocs}]
> [INFO] Not executing Javadoc as the project is not a Java classpath-capable package
> [INFO] [license:check {execution: default}]
> [INFO] Checking licenses...
> [INFO] [rat:check {execution: default}]
> [INFO] [install:install {execution: default-install}]
> [INFO] Installing <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-examples/pom.xml>
to /home/hudson/.m2/repository/org/apache/empire-db/empire-db-examples/2.0.6-incubating-SNAPSHOT/empire-db-examples-2.0.6-incubating-SNAPSHOT.pom
> [INFO] [deploy:deploy {execution: default-deploy}]
> [INFO]  skipping artifact deployement
> [INFO] ------------------------------------------------------------------------
> [INFO] Building Apache Empire-db Basic Example
> [INFO]    task-segment: [clean, install, deploy]
> [INFO] ------------------------------------------------------------------------
> [INFO] [clean:clean {execution: default-clean}]
> [INFO] Deleting file set: <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-examples/empire-db-example-basic/target>
(included: [**], excluded: [])
> [INFO] [enforcer:enforce {execution: enforce-versions}]
> [INFO] [remote-resources:process {execution: default}]
> [INFO] [resources:resources {execution: default-resources}]
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-examples/empire-db-example-basic/src/main/resources>
> [INFO] Copying 4 resources
> [INFO] [compiler:compile {execution: default-compile}]
> [INFO] Compiling 4 source files to <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-examples/empire-db-example-basic/target/classes>
> [INFO] [resources:testResources {execution: default-testResources}]
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-examples/empire-db-example-basic/src/test/resources>
> [INFO] Copying 4 resources
> [INFO] [compiler:testCompile {execution: default-testCompile}]
> [INFO] No sources to compile
> [INFO] [surefire:test {execution: default-test}]
> [INFO] Surefire report directory: <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-examples/empire-db-example-basic/target/surefire-reports>
>
> -------------------------------------------------------
>  T E S T S
> -------------------------------------------------------
> There are no tests to run.
>
> Results :
>
> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
>
> [INFO] [jar:jar {execution: default-jar}]
> [INFO] Building jar: <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-examples/empire-db-example-basic/target/empire-db-example-basic-2.0.6-incubating-SNAPSHOT.jar>
> [INFO] Preparing source:jar
> [WARNING] Removing: jar from forked lifecycle, to prevent recursive invocation.
> [INFO] [enforcer:enforce {execution: enforce-versions}]
> [INFO] [source:jar {execution: attach-sources}]
> [INFO] Building jar: <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-examples/empire-db-example-basic/target/empire-db-example-basic-2.0.6-incubating-SNAPSHOT-sources.jar>
> [INFO] [javadoc:jar {execution: attach-javadocs}]
> Loading source files for package org.apache.empire.samples.db...
> Constructing Javadoc information...
> Standard Doclet version 1.5.0_22
> Building tree for all the packages and classes...
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-examples/empire-db-example-basic/target/apidocs/org/apache/empire/samples/db//SampleApp.html...>
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-examples/empire-db-example-basic/target/apidocs/org/apache/empire/samples/db//SampleBean.html...>
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-examples/empire-db-example-basic/target/apidocs/org/apache/empire/samples/db//SampleConfig.html...>
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-examples/empire-db-example-basic/target/apidocs/org/apache/empire/samples/db//SampleDB.html...>
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-examples/empire-db-example-basic/target/apidocs/org/apache/empire/samples/db//SampleDB.Departments.html...>
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-examples/empire-db-example-basic/target/apidocs/org/apache/empire/samples/db//SampleDB.Employees.html...>
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-examples/empire-db-example-basic/target/apidocs/org/apache/empire/samples/db//package-frame.html...>
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-examples/empire-db-example-basic/target/apidocs/org/apache/empire/samples/db//package-summary.html...>
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-examples/empire-db-example-basic/target/apidocs/org/apache/empire/samples/db//package-tree.html...>
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-examples/empire-db-example-basic/target/apidocs/constant-values.html...>
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-examples/empire-db-example-basic/target/apidocs/org/apache/empire/samples/db/class-use//SampleBean.html...>
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-examples/empire-db-example-basic/target/apidocs/org/apache/empire/samples/db/class-use//SampleDB.html...>
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-examples/empire-db-example-basic/target/apidocs/org/apache/empire/samples/db/class-use//SampleDB.Departments.html...>
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-examples/empire-db-example-basic/target/apidocs/org/apache/empire/samples/db/class-use//SampleDB.Employees.html...>
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-examples/empire-db-example-basic/target/apidocs/org/apache/empire/samples/db/class-use//SampleApp.html...>
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-examples/empire-db-example-basic/target/apidocs/org/apache/empire/samples/db/class-use//SampleConfig.html...>
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-examples/empire-db-example-basic/target/apidocs/org/apache/empire/samples/db//package-use.html...>
> Building index for all the packages and classes...
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-examples/empire-db-example-basic/target/apidocs/overview-tree.html...>
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-examples/empire-db-example-basic/target/apidocs/index-all.html...>
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-examples/empire-db-example-basic/target/apidocs/deprecated-list.html...>
> Building index for all classes...
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-examples/empire-db-example-basic/target/apidocs/allclasses-frame.html...>
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-examples/empire-db-example-basic/target/apidocs/allclasses-noframe.html...>
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-examples/empire-db-example-basic/target/apidocs/index.html...>
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-examples/empire-db-example-basic/target/apidocs/help-doc.html...>
> Generating <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-examples/empire-db-example-basic/target/apidocs/stylesheet.css...>
> [INFO] Building jar: <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-examples/empire-db-example-basic/target/empire-db-example-basic-2.0.6-incubating-SNAPSHOT-javadoc.jar>
> [INFO] [license:check {execution: default}]
> [INFO] Checking licenses...
> [INFO] Missing header in: <http://hudson.zones.apache.org/hudson/job/Empire-DB%20snapshot/ws/trunk/empire-db-examples/empire-db-example-basic/config.xml>
> [INFO] ------------------------------------------------------------------------
> [ERROR] BUILD ERROR
> [INFO] ------------------------------------------------------------------------
> [INFO] Some files do not have the expected license header
> [INFO] ------------------------------------------------------------------------
> [INFO] For more information, run Maven with the -e switch
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 1 minute 3 seconds
> [INFO] Finished at: Thu Nov 19 15:35:21 UTC 2009
> [INFO] Final Memory: 44M/195M
> [INFO] ------------------------------------------------------------------------
> Recording test results
>
>



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

Hi everyone,

thanks for everything you've done and I apologize for not being able to participate more frequently
at the moment.
But I will have a look at the code generator this weekend.

As far as your thought's are concerned:
My idea is that in the end the codegen should (primarily) become a Maven plugin. 
During development it is probably easier to have a console application, but it should indeed
be kept independent as Francis suggests.

About sl4j: I don't know much about the benefits compared to log4j. I have briefly followed
the link you provided but did not have time to get into further detail. So far I have never
had problems with log4j. 
The question is: Wouldn't we have to switch the entire project and not just the codegen to
slf4j and is it really worth it? If it's worth I wouldn't mind changing, but it's not on the
top of my list.

Regards
Rainer


Francis De Brabandere wrote:
> re: Some thoughts
> 
> Hi all,
> 
> I cleaned up the code generator a bit. I hope I'm not too much
> interfering with you guys. Let me know if you don't agree with this
> way of working...
> 
> Some thoughts:
> 
> [codegen]
> - I think we should try to keep the code generator independent from
> the console application so that we can easily create and IDE or Maven
> plugin for the code generator.
> - We need to think about how to support multiple database vendors. I'm
> willing to have a go at a MySQL/Postgre version once we have torn out
> the database-specific stuff in one or more separate class(es).
> 
> [general]
> - I'm a big fan of (unit) testing so I will probably add tests here
> and there over time... Automated integrations tests for HSQLDB, H2 and
> Derby should be possible. On the other hand testing is mostly of the
> time easier when using composition instead of inheritance.
> - I'd like to suggest to move to slf4j for logging as there are known
> issues with commons logging. See this page for some background info:
> http://www.slf4j.org/faq.html#yet_another_facade
> 
> Cheers,
> Francis
> 
> --
> http://www.somatik.be
> Microsoft gives you windows, Linux gives you the whole house.

Hi Francis,

just had a look at your changes ... seems there is the dependency for 
mockito in the pom.xml missing.
... will have a more detailed look at the other stuff later this week.

regards
    benjamin

Francis De Brabandere schrieb:
> Hi all,
>
> I cleaned up the code generator a bit. I hope I'm not too much
> interfering with you guys. Let me know if you don't agree with this
> way of working...
>
> Some thoughts:
>
> [codegen]
> - I think we should try to keep the code generator independent from
> the console application so that we can easily create and IDE or Maven
> plugin for the code generator.
> - We need to think about how to support multiple database vendors. I'm
> willing to have a go at a MySQL/Postgre version once we have torn out
> the database-specific stuff in one or more separate class(es).
>
> [general]
> - I'm a big fan of (unit) testing so I will probably add tests here
> and there over time... Automated integrations tests for HSQLDB, H2 and
> Derby should be possible. On the other hand testing is mostly of the
> time easier when using composition instead of inheritance.
> - I'd like to suggest to move to slf4j for logging as there are known
> issues with commons logging. See this page for some background info:
> http://www.slf4j.org/faq.html#yet_another_facade
>
> Cheers,
> Francis
>
>   

Hi all,

I cleaned up the code generator a bit. I hope I'm not too much
interfering with you guys. Let me know if you don't agree with this
way of working...

Some thoughts:

[codegen]
- I think we should try to keep the code generator independent from
the console application so that we can easily create and IDE or Maven
plugin for the code generator.
- We need to think about how to support multiple database vendors. I'm
willing to have a go at a MySQL/Postgre version once we have torn out
the database-specific stuff in one or more separate class(es).

[general]
- I'm a big fan of (unit) testing so I will probably add tests here
and there over time... Automated integrations tests for HSQLDB, H2 and
Derby should be possible. On the other hand testing is mostly of the
time easier when using composition instead of inheritance.
- I'd like to suggest to move to slf4j for logging as there are known
issues with commons logging. See this page for some background info:
http://www.slf4j.org/faq.html#yet_another_facade

Cheers,
Francis

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

Will apply this patch this evening.
Cheers,
Francis

On Nov 14, 2009 3:30 p.m., "Benjamin Venditti" <benniven@web.de> wrote:

Hi there,

I have uploaded a new patch that will get rid of the additional Database,
Table and Column bean classes.
The codegen now uses the empire DBDatabase, DBTable and DBColumn classes
instead.

The patch contains the following changes:
modifications:
 - CodeGen.java
 - CodeGenConfig.java    // option named "tableClassSuffix" added
 - config.xml                     // option named "tableClassSuffix" added
 - Database.vm
 - Record.vm
 - Table.vm

deletions:
 - package org.apache.empire.db.codegen.types
 - StringUtils.java  // partly moved to ParserUtil.java

additions:
 - CodeGenParser.java  // Used to create a empty DBDatabase and to populate
that
 - ParserUtil.java           // Used by the velocity templates to get
strings like accessor name, mutator name, table class name, record class
name

I think we should go through the configuation options in CodeGenConfig, as
there are still some things in the templates that are hardcoded, like e.g.
the "T_" of the variable names. I'll propose a list with configuation
options soon.

Regards
  Benjamin

2nd call :-)

Anybody going to devoxx?

Cheers,
Francis

On Fri, Aug 28, 2009 at 8:23 AM, Francis De Brabandere
<francisdb@gmail.com> wrote:
> Attending. And yes it it's in Antwerp: http://www.javoxx.com/display/DV09/Venue
>
> On Fri, Aug 28, 2009 at 8:26 AM, Rainer Döbele<doebele@esteam.de> wrote:
>>
>> It says when it is but I could not find out quickly where it is.
>> But since apparently the last one was in Antwerp, Belgium I guess it will be there
again.
>>
>> Unfortunately Francis I will probably not be able to make it.
>> But I really hope we can all meet one day.
>>
>> What excactly are you doing there (attending, organizing, speaking?)
>>
>> Regards
>> Rainer
>>
>>
>> Francis De Brabandere wrote:
>>> re: empire-db-dev@incubator.apache.org
>>> Betreff: devoxx
>>>
>>> Hi,
>>>
>>> Is any of you going to devoxx?
>>> http://www.javoxx.com/display/DV09
>>> I'll be there the whole week.
>>>
>>> Cheers,
>>> Francis
>>>
>>> --
>>> http://www.somatik.be
>>> Microsoft gives you windows, Linux gives you the whole house.
>>
>
>
>
> --
> http://www.somatik.be
> Microsoft gives you windows, Linux gives you the whole house.
>



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

Hi there,

I have uploaded a new patch that will get rid of the additional 
Database, Table and Column bean classes.
The codegen now uses the empire DBDatabase, DBTable and DBColumn classes 
instead.

The patch contains the following changes:
 modifications:
  - CodeGen.java
  - CodeGenConfig.java    // option named "tableClassSuffix" added
  - config.xml                     // option named "tableClassSuffix" added
  - Database.vm
  - Record.vm
  - Table.vm

deletions:
  - package org.apache.empire.db.codegen.types
  - StringUtils.java  // partly moved to ParserUtil.java

additions:
  - CodeGenParser.java  // Used to create a empty DBDatabase and to 
populate that
  - ParserUtil.java           // Used by the velocity templates to get 
strings like accessor name, mutator name, table class name, record class 
name

I think we should go through the configuation options in CodeGenConfig, 
as there are still some things in the templates that are hardcoded, like 
e.g. the "T_" of the variable names. I'll propose a list with 
configuation options soon.

Regards
    Benjamin

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

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

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.

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

I  put a reference on our wiki.

http://cwiki.apache.org/confluence/display/empiredb/Similar+Projects


On Wed, Aug 5, 2009 at 4:26 PM, Matthew Bond <bond@esteam.de> wrote:
> Hi Dev Team,
>
> I just found JaQu which is also uses a similar idea as does Empire-db
> http://www.h2database.com/html/jaqu.html
>
> They also reference our project on their web page.
>
> Matt Bond
>
>
>



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

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

I'm willing to test on mysql/postgre but I think we need a decent test
case for each of them so that we can rerun tests in the future...

On Sun, Nov 1, 2009 at 12:29 PM, Rainer Döbele <doebele@esteam.de> wrote:
> 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.

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

Just came across a very old article and a recent blog that are interesting to read.

http://www.codinghorror.com/blog/archives/000621.html
and
http://go.techtarget.com/r/9694083/2839727

Rainer

Okay, found it out by myself.
I had to log in first :P.



Benjamin Venditti schrieb:
> Hello Marijn,
>
> I have a new eclipse-patch ready that considers rainers changes.
> Could you please explain me how i can submitt the patch in JIRA?
>
> I've already tried the following link, however haven't seen a "submit 
> code" button or something similar.
>
>    https://issues.apache.org/jira/browse/EMPIREDB/component/12313027
>
> Regards,
>    Benjamin
>
> Martijn Dashorst schrieb:
>> On Mon, Oct 26, 2009 at 11:19 PM, Rainer Döbele <doebele@esteam.de> 
>> wrote:
>>  
>>> Would you be able to send me a patch for your changed based on the 
>>> code in the repository?
>>>     
>>
>> Use JIRA for this. It is the official communication protocol between
>> non-committers and committers. Sending patches privately ensures that
>> only one person can work and evaluate the patch. Having it available
>> in JIRA gives the whole team access.
>>
>> Martijn
>>   
>

Hello Marijn,

I have a new eclipse-patch ready that considers rainers changes.
Could you please explain me how i can submitt the patch in JIRA?

I've already tried the following link, however haven't seen a "submit 
code" button or something similar.

    https://issues.apache.org/jira/browse/EMPIREDB/component/12313027

Regards,
    Benjamin

Martijn Dashorst schrieb:
> On Mon, Oct 26, 2009 at 11:19 PM, Rainer Döbele <doebele@esteam.de> wrote:
>   
>> Would you be able to send me a patch for your changed based on the code in the repository?
>>     
>
> Use JIRA for this. It is the official communication protocol between
> non-committers and committers. Sending patches privately ensures that
> only one person can work and evaluate the patch. Having it available
> in JIRA gives the whole team access.
>
> Martijn
>   

On Mon, Oct 26, 2009 at 11:19 PM, Rainer Döbele <doebele@esteam.de> wrote:
> Would you be able to send me a patch for your changed based on the code in the repository?

Use JIRA for this. It is the official communication protocol between
non-committers and committers. Sending patches privately ensures that
only one person can work and evaluate the patch. Having it available
in JIRA gives the whole team access.

Martijn

Hi everyone,

 

I have just checked in the code submitted by Thomas which I have merged with my project skeleton.

 

Just after I had submitted the code I found Benjamin's message with his patch.

So it seems that we concurrently made some changes.

 

Sorry Benjamin, I won't be able to look at your code tonight.

Please check out the current state of the empire-db-codegen and work with the code from the
repository.

Would you be able to send me a patch for your changed based on the code in the repository?

 

I have modified a few things like getting rid of the DataSource.

This is a starting point and before we continue adding more features we should review and
improve the overall architecture.

 

Regards

 

Rainer

 

I'm sorry,

the patch contained a little bug. here is the fixed one.

Regards
    Benjamin


Benjamin Venditti schrieb:
> Hi there,
>
> i have crated a eclipse-patch that contains the codegenerator with 
> very basic functionality.
> I have taken care of multi-column primary keys, the connection stuff 
> as well as the unclosed ResultSets.
>
> The generator is quit basic at the moment and the following will not 
> work:
>    - column specific getters/setters on specific records
>    - nested table generation within the database
>    - relation mapping (foreign key dependencies)
>    - locking columns
>    - views
>    - name prefix for tables, views
>    - configuration of schemaPattern, catalogName, tablePattern, this 
> is hardcoded at the moment with (null, null, null) see "// TODO 01" in 
> the sourcecode.
>
> A additional configuration option was added named "outputFolder" this 
> is the folder where the generated sourcode will be stored.
>
> I'd be happy if anyone could have a look at it.
>
> Regards
>    Benjamin
>
> Rainer Döbele schrieb:
>> Hi Benni,
>>
>> yes I would be grateful if you could do that.
>> We just have to make sure that we don't work on the same subject.
>>
>> The first goal should be to create a connection and generate the 
>> database and table classes.
>> Thomas is using a BasicDataSource for connection pooling.
>> However I don't think we need to do that. I'd rather have a simple 
>> JDBC connection like the one we use in our samples.
>>
>> Further we need to find a solution for detecting the primary key column.
>> We cannot assume the primary key is always a single column with the 
>> same name throughout the db.
>>
>> What I also found is that ResultSets obtained for reading meta data 
>> are not always closed.
>> e.g. ResultSet tables = dbMeta.getTables(...)
>> should be closed in a finally block.
>>
>> Rather than trying to get over as much code as possible we should 
>> carefully rethink how we can improve the overall architecture and do 
>> several small steps instead of one big one. I am convinced this will 
>> lead to a better solution.
>>
>> So please let me know until when you think you can come up with the 
>> first classes to integrate.
>>
>> Regards
>> Rainer
>>
>>
>> benniven@web.de wrote:
>>  
>>> Re: Starting with Empire-db code generator
>>>
>>> Hi,
>>>
>>> I had a look at the classes rainer provided in the repository and at
>>> those of thomas. I think we can reuse a large part of thomas' code,
>>> however we'll have to rewrite some things like the table generation
>>> part
>>> and remove some things like configuration and connection stuff (rainer
>>> already provided that in the repo).
>>>
>>> So my suggestion is to migrate thomas' code with its functionality and
>>> behavior as it is for now and adapt/rewrite it in the next steps to our
>>> needs. Please let me know what you think. I'd be happy to start with
>>> the
>>> migration soon.
>>>
>>> Regards
>>>     Benjamin
>>>
>>> Rainer Döbele schrieb:
>>>    
>>>> Hi,
>>>>
>>>> I will have a look at it this weekend.
>>>> I am sorry, but I have just been very very busy recently.
>>>>
>>>> Regards
>>>> Rainer
>>>>
>>>>
>>>> Francis De Brabandere wrote:
>>>>
>>>>      
>>>>> Re: Starting with Empire-db code generator
>>>>>
>>>>> What should be done to get this going?
>>>>>
>>>>> On Thu, Oct 15, 2009 at 1:09 PM, Martijn Dashorst
>>>>> <martijn.dashorst@gmail.com> wrote:
>>>>>
>>>>>        
>>>>>> On Mon, Oct 12, 2009 at 9:28 AM, Rainer Döbele <doebele@esteam.de>
>>>>>>
>>>>>>           
>>>>> wrote:
>>>>>
>>>>>        
>>>>>>> the current code is IMO not flexible enough and even more
>>>>>>>             
>>> important
>>>    
>>>>> it is Thomas' code and I see legal problems in just copying the
>>>>>         
>>> code.
>>>    
>>>>>> As long as Thomas has signed a CLA, wrote the code, and is allowed
>>>>>>           
>>> to
>>>    
>>>>>> license it to the ASF, there are no legal problems in copying the
>>>>>> code.
>>>>>>
>>>>>> Martijn
>>>>>>
>>>>>>
>>>>>>           
>>>>> -- 
>>>>> http://www.somatik.be
>>>>> Microsoft gives you windows, Linux gives you the whole house.
>>>>>
>>>>>         
>>
>>   
>

Hi there,

i have crated a eclipse-patch that contains the codegenerator with very 
basic functionality.
I have taken care of multi-column primary keys, the connection stuff as 
well as the unclosed ResultSets.

The generator is quit basic at the moment and the following will not work:
    - column specific getters/setters on specific records
    - nested table generation within the database
    - relation mapping (foreign key dependencies)
    - locking columns
    - views
    - name prefix for tables, views
    - configuration of schemaPattern, catalogName, tablePattern, this is 
hardcoded at the moment with (null, null, null) see "// TODO 01" in the 
sourcecode.

A additional configuration option was added named "outputFolder" this is 
the folder where the generated sourcode will be stored.

I'd be happy if anyone could have a look at it.

Regards
    Benjamin

Rainer Döbele schrieb:
> Hi Benni,
>
> yes I would be grateful if you could do that.
> We just have to make sure that we don't work on the same subject.
>
> The first goal should be to create a connection and generate the database and table classes.
> Thomas is using a BasicDataSource for connection pooling.
> However I don't think we need to do that. I'd rather have a simple JDBC connection like
the one we use in our samples.
>
> Further we need to find a solution for detecting the primary key column.
> We cannot assume the primary key is always a single column with the same name throughout
the db.
>
> What I also found is that ResultSets obtained for reading meta data are not always closed.
> e.g. ResultSet tables = dbMeta.getTables(...)
> should be closed in a finally block.
>
> Rather than trying to get over as much code as possible we should carefully rethink how
we can improve the overall architecture and do several small steps instead of one big one.
I am convinced this will lead to a better solution.
>
> So please let me know until when you think you can come up with the first classes to
integrate.
>
> Regards
> Rainer
>
>
> benniven@web.de wrote:
>   
>> Re: Starting with Empire-db code generator
>>
>> Hi,
>>
>> I had a look at the classes rainer provided in the repository and at
>> those of thomas. I think we can reuse a large part of thomas' code,
>> however we'll have to rewrite some things like the table generation
>> part
>> and remove some things like configuration and connection stuff (rainer
>> already provided that in the repo).
>>
>> So my suggestion is to migrate thomas' code with its functionality and
>> behavior as it is for now and adapt/rewrite it in the next steps to our
>> needs. Please let me know what you think. I'd be happy to start with
>> the
>> migration soon.
>>
>> Regards
>>     Benjamin
>>
>> Rainer Döbele schrieb:
>>     
>>> Hi,
>>>
>>> I will have a look at it this weekend.
>>> I am sorry, but I have just been very very busy recently.
>>>
>>> Regards
>>> Rainer
>>>
>>>
>>> Francis De Brabandere wrote:
>>>
>>>       
>>>> Re: Starting with Empire-db code generator
>>>>
>>>> What should be done to get this going?
>>>>
>>>> On Thu, Oct 15, 2009 at 1:09 PM, Martijn Dashorst
>>>> <martijn.dashorst@gmail.com> wrote:
>>>>
>>>>         
>>>>> On Mon, Oct 12, 2009 at 9:28 AM, Rainer Döbele <doebele@esteam.de>
>>>>>
>>>>>           
>>>> wrote:
>>>>
>>>>         
>>>>>> the current code is IMO not flexible enough and even more
>>>>>>             
>> important
>>     
>>>> it is Thomas' code and I see legal problems in just copying the
>>>>         
>> code.
>>     
>>>>> As long as Thomas has signed a CLA, wrote the code, and is allowed
>>>>>           
>> to
>>     
>>>>> license it to the ASF, there are no legal problems in copying the
>>>>> code.
>>>>>
>>>>> Martijn
>>>>>
>>>>>
>>>>>           
>>>> --
>>>> http://www.somatik.be
>>>> Microsoft gives you windows, Linux gives you the whole house.
>>>>
>>>>         
>
>   

Hi Benni,

yes I would be grateful if you could do that.
We just have to make sure that we don't work on the same subject.

The first goal should be to create a connection and generate the database and table classes.
Thomas is using a BasicDataSource for connection pooling.
However I don't think we need to do that. I'd rather have a simple JDBC connection like the
one we use in our samples.

Further we need to find a solution for detecting the primary key column.
We cannot assume the primary key is always a single column with the same name throughout the
db.

What I also found is that ResultSets obtained for reading meta data are not always closed.
e.g. ResultSet tables = dbMeta.getTables(...)
should be closed in a finally block.

Rather than trying to get over as much code as possible we should carefully rethink how we
can improve the overall architecture and do several small steps instead of one big one. I
am convinced this will lead to a better solution.

So please let me know until when you think you can come up with the first classes to integrate.

Regards
Rainer


benniven@web.de wrote:
> Re: Starting with Empire-db code generator
> 
> Hi,
> 
> I had a look at the classes rainer provided in the repository and at
> those of thomas. I think we can reuse a large part of thomas' code,
> however we'll have to rewrite some things like the table generation
> part
> and remove some things like configuration and connection stuff (rainer
> already provided that in the repo).
> 
> So my suggestion is to migrate thomas' code with its functionality and
> behavior as it is for now and adapt/rewrite it in the next steps to our
> needs. Please let me know what you think. I'd be happy to start with
> the
> migration soon.
> 
> Regards
>     Benjamin
> 
> Rainer Döbele schrieb:
> > Hi,
> >
> > I will have a look at it this weekend.
> > I am sorry, but I have just been very very busy recently.
> >
> > Regards
> > Rainer
> >
> >
> > Francis De Brabandere wrote:
> >
> >> Re: Starting with Empire-db code generator
> >>
> >> What should be done to get this going?
> >>
> >> On Thu, Oct 15, 2009 at 1:09 PM, Martijn Dashorst
> >> <martijn.dashorst@gmail.com> wrote:
> >>
> >>> On Mon, Oct 12, 2009 at 9:28 AM, Rainer Döbele <doebele@esteam.de>
> >>>
> >> wrote:
> >>
> >>>> the current code is IMO not flexible enough and even more
> important
> >>>>
> >> it is Thomas' code and I see legal problems in just copying the
> code.
> >>
> >>> As long as Thomas has signed a CLA, wrote the code, and is allowed
> to
> >>> license it to the ASF, there are no legal problems in copying the
> >>> code.
> >>>
> >>> Martijn
> >>>
> >>>
> >>
> >> --
> >> http://www.somatik.be
> >> Microsoft gives you windows, Linux gives you the whole house.
> >>

Hi Thomas,

thanks again for your code submission.
I have only now found some time to look at it and found that it needs some modifications before
I can check it in.
I think I can do some of the work next week.

Rainer


Thomas Poling wrote:
> re: No Frills Code Generator
>
> Greetings All:
> I'm finally back - a lot of business travel and a little, well deserved, vacation.
> I think I've gathered all the ideas and will submit the attached jar as a starting point
for the code generator.
> I just submitted the CLA form late last week but if you want to get this project into
the svn repository quickly you have my permission to use the attached source as a starting
point.
> 
> Please let me know what you think and more importantly what I left out or misinterpreted.
> Thanks, Tom

Hi,

I had a look at the classes rainer provided in the repository and at 
those of thomas. I think we can reuse a large part of thomas' code, 
however we'll have to rewrite some things like the table generation part 
and remove some things like configuration and connection stuff (rainer 
already provided that in the repo).

So my suggestion is to migrate thomas' code with its functionality and 
behavior as it is for now and adapt/rewrite it in the next steps to our 
needs. Please let me know what you think. I'd be happy to start with the 
migration soon.

Regards
    Benjamin

Rainer Döbele schrieb:
> Hi,
>
> I will have a look at it this weekend.
> I am sorry, but I have just been very very busy recently.
>
> Regards
> Rainer
>
>
> Francis De Brabandere wrote:
>   
>> Re: Starting with Empire-db code generator
>>
>> What should be done to get this going?
>>
>> On Thu, Oct 15, 2009 at 1:09 PM, Martijn Dashorst
>> <martijn.dashorst@gmail.com> wrote:
>>     
>>> On Mon, Oct 12, 2009 at 9:28 AM, Rainer Döbele <doebele@esteam.de>
>>>       
>> wrote:
>>     
>>>> the current code is IMO not flexible enough and even more important
>>>>         
>> it is Thomas' code and I see legal problems in just copying the code.
>>     
>>> As long as Thomas has signed a CLA, wrote the code, and is allowed to
>>> license it to the ASF, there are no legal problems in copying the
>>> code.
>>>
>>> Martijn
>>>
>>>       
>>
>> --
>> http://www.somatik.be
>> Microsoft gives you windows, Linux gives you the whole house.
>>