You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@empire-db.apache.org by Benjamin Venditti <be...@web.de> on 2009/09/07 17:13:57 UTC
Re: suggestions for improving Thomas' DBGenerataor
Hi Rainer & Thomas
i'm currently a little busy as i'm moving to vienna this month, but i
haven't forgotten DBGenerator ;-) .
I agree with the most of rainer's suggestions:
1. A database class needs no connection stuff inside. --> So the
database will get configured via the constuctor.
2. A empty (for the beginning) in between table class named XXXTable
(XXX is a userdefined prefix), so the user (developer) may add methods
there.
3. Just put the basics to a individual record class, so no
locking/attribute getters or relationship finders.
4. The common XXXRecord (XXX is a userdefined prefix) class should
utilize generics.
I hope i got it right so far.
Thomas, what do you think about these changes?
best regards,
benjamin
Rainer Döbele schrieb:
> Hi Thomas, Hi Benni,
>
> finally I found the time to take a closer look at the DBGenerataor and what you are doing there looks very promising already.
>
> So far most conversation has been on the empire-db-user mailing list. I would recommend moving it to the empire-db-dev mailing list. I am not sure, whether Thomas is subscribed to this list and if he has received Benjamin's last message (see below).
>
> At the moment the database connection is hard-coded in DbCodeGenerator::main which is obviously not a good idea but should be easy to fix. Thanks Benni for mavenizing the project - Thomas are you happy with that?
>
> As far as the generated code is concerned we should first decide what is absolutely necessary and what are individual extensions that possibly could be added manually later. I for example do not find the necessity to generate the interfaces IRecord and IBaseRecord (besides the "I"- prefix is not commonly used in Java). Once the Record class has been generated e.g. anyone can manually extend it and generate an interface for the class.
>
> What I would recommend to generate is the following:
>
> - The database class, but only with the definition and without all the connection stuff. A database may be used in more than one instance with different connections and thus it's not necessarily a singleton.
>
> - A base table class that goes between DBTable and the actual individual table classes. The name should be configurable (if it is XXXDatabase it should be XXXTable). This class can be empty at first so that the user can add methods there. I always create such an in-between table class in my projects and I use it for auto-setting fields like user-names or create-timestamps. It's very convenient.
>
> - The individual table classes, possibly with an option to generate top level classes (individual files) or to create them as nested classes inside the database class (if this is possible).
>
> - A base record class as you have done, but the class signature should be as follows:
>
> public class XXXRecord<T extends XXXTable> extends DBRecord
>
> Using generics here brings a real advantage, as the base record class can then use properties and methods of the base table class.
>
> - The individual record classes. Personally I don't like and need the access methods for simple attributes and the finder methods (they make it look like OR-Mapper beans and people may use them like that). The purpose of these classes should be mainly to override methods like getFieldOptions, update and delete.
>
>
> These are my suggestions. I would appreciate if you would be willing to work with us any possibly donate your code to the ASF so that we can supply it with a future release of Empire-db. In this case we could add the code to our svn repository so that you can all conveniently work on it.
>
> What do you think?
>
> Regards,
> Rainer
>
>
> Benniven wrote:
>
>> re: automatic empire-db driver configuration | mavenizing
>>
>> Hi there,
>>
>> i added the code to the Database.vm template so that it can
>> automatically configure the desired EmpireDB driver.
>> I used jetty's XMLConfiguration class to do that. I also mavenized the
>> project, so that it is easier to get it running.
>> Please let me know what you think of it.
>>
>> Modified files:
>> Database.vm
>> Database.java
>> DbCodeGenerator.java
>>
>> New files:
>> database-configuration.xml
>> pom.xml
>>
>> thanks in advance
>> benni
>>
>> WARNING:
>> I currently use HSQL for testing. I therefore had to modify all the
>> database meta-data retrieving code in the file Table.java.
>> e.g. the line:
>> ResultSet fkRs = dbMeta.getImportedKeys(schema, null ,
>> tableName);
>> was changed to:
>> ResultSet fkRs = dbMeta.getImportedKeys(null, schema,
>> tableName);
>>
Re: Empire-db code generator
Posted by Benjamin Venditti <be...@web.de>.
Hi Rainer,
I'm already subscribed to empire-dev and empire-user mailinglists. I
think your suggestion is meaningful. As for me, I'd be happy to work
that way and I'm looking forward to work with you.
best regards
Benjamin
Rainer Döbele schrieb:
> Hi Thomas and Benni,
>
> we are not planning to create a new subproject or component of empire-db called the Code Generator for which we would like to invite you for collaboration.
>
> My idea is to create an initial simple project in SVN which you can then obtain via the public svn access
> http://svn.apache.org/repos/asf/incubator/empire-db/trunk
> Then I will create a corresponding JIRA task that allows you to submit your code though JIRA.
> https://issues.apache.org/jira/browse/EMPIREDB
> (Thomas: you would have to fill out and submit an CLA beforehand http://www.apache.org/licenses/#clas)
> Whenever you submit code through JIRA I will then check it in to the svn repository.
>
> At the moment we're still struggling to get our 2-0-5 release approved by the incubator project mangement committee (IPMC) and before I start creating the Code Generator project I would like to see this release approved - which might take another week.
>
> Is this OK by you and are you willing to work this way?
>
> Are you both subscribed to the empire-db-dev mailing list yet?
>
> Regards
> Rainer
>
>
> benniven wrote:
>
>> Re: suggestions for improving Thomas' DBGenerataor
>>
>> Hi there,
>>
>> thank you martijn for the detailed information. In fact i have already
>> signed and sent a CLA a few months ago.
>> I just signed up at Empire-db on JIRA and tried to figure out how
>> attach
>> code to a jira ticket. However i couldn't #
>> find the tickets you mentioned, I just found the issues that are
>> reported but couldn't find a way how to attach code to one of them.
>>
>> Should therefore a new issue or ticket be opend? How is that done and
>> how to attach code to it?
>>
>> Thanks in advance.
>>
>> best regards
>> benjamin
>>
>> Martijn Dashorst schrieb:
>>
>>> Benjamin, Thomas,
>>>
>>> First of all, thank you for your contributions and continued support
>>> for this project. Contrary to what Rainer has stated, your code can
>>> become part of Empire-db, and you can become committers, though not
>>> immediately. Let me describe these two things in more detail. First
>>> concerning your code.
>>>
>>> If you wish to submit your code for inclusion in the Empire-db
>>> project, you should attach the code to a JIRA ticket
>>> (http://issues.apache.org/jira/browse/EMPIREDB) and make sure you
>>> specify that you intend to have the code be included in Apache
>>> software. It would be even better if you would sign and submit a
>>> Contributor License Agreement (CLA), specifying that you license the
>>> code you commit (or have others commit) to the Apache Software
>>> Foundation.
>>>
>>> Read [1] for more information about the need for CLAs and for
>>> instructions on how to send one in, see [2] for the text version of
>>> the CLA and [3] for the PDF version. If you have questions concerning
>>> CLAs don't hesitate to ask.
>>>
>>> Once the code is in JIRA, and have the appropriate licensing in place
>>> (either the checkbox or a CLA on file), the Empire-db committers can
>>> include the code in the project.
>>>
>>> Now on becoming a committer.
>>>
>>> You are encouraged to continue to work on the code (of dbgenerator
>>> *and* the whole of empire-db!). You should ensure that your code
>>>
>> style
>>
>>> and formatting follows the guidelines set forward by the Empire-db
>>> project. If you have changes, please submit a patch with your changes
>>> (unified diff works best with Eclipse and svn). The Empire-db
>>> committers will evaluate the patch, perhaps suggest improvements, and
>>> soon apply it to the code base. You are welcome to submit patches for
>>> anything in the project (not limited to the generator code).
>>>
>>> When your patches are plentiful, and can be applied easily, the
>>> Empire-db project members can elect to grant you direct access to the
>>> code repository. Usually this happens when they get tired of applying
>>> your patches, and want you to do the work yourself. The idea is that
>>> people who have shown a continued interest in the project and are
>>> actively involved [writing code (*)] should be rewarded with
>>> committership. This is at the core of how the ASF works: a
>>>
>> meritocracy
>>
>>> [4,5].
>>>
>>> (*) there are also Committers who don't write code, but gaining merit
>>> for non-coders is usually more difficult than for coders
>>>
>>> If you have any questions, please let me know.
>>>
>>> Martijn
>>>
>>> [1] About Contributor License Agreements:
>>>
>> http://www.apache.org/licenses/#clas
>>
>>> [2] The CLA (text): http://www.apache.org/licenses/icla.txt
>>> [3] The CLA (PDF): http://www.apache.org/licenses/icla.pdf
>>> [4] About Meritocracy:
>>> http://www.apache.org/foundation/how-it-works.html#meritocracy
>>> [5] About contributing:
>>>
>> http://www.apache.org/foundation/getinvolved.html
>>
>
>
Empire-db code generator
Posted by Rainer Döbele <do...@esteam.de>.
Hi Thomas and Benni,
we are not planning to create a new subproject or component of empire-db called the Code Generator for which we would like to invite you for collaboration.
My idea is to create an initial simple project in SVN which you can then obtain via the public svn access
http://svn.apache.org/repos/asf/incubator/empire-db/trunk
Then I will create a corresponding JIRA task that allows you to submit your code though JIRA.
https://issues.apache.org/jira/browse/EMPIREDB
(Thomas: you would have to fill out and submit an CLA beforehand http://www.apache.org/licenses/#clas)
Whenever you submit code through JIRA I will then check it in to the svn repository.
At the moment we're still struggling to get our 2-0-5 release approved by the incubator project mangement committee (IPMC) and before I start creating the Code Generator project I would like to see this release approved - which might take another week.
Is this OK by you and are you willing to work this way?
Are you both subscribed to the empire-db-dev mailing list yet?
Regards
Rainer
benniven wrote:
> Re: suggestions for improving Thomas' DBGenerataor
>
> Hi there,
>
> thank you martijn for the detailed information. In fact i have already
> signed and sent a CLA a few months ago.
> I just signed up at Empire-db on JIRA and tried to figure out how
> attach
> code to a jira ticket. However i couldn't #
> find the tickets you mentioned, I just found the issues that are
> reported but couldn't find a way how to attach code to one of them.
>
> Should therefore a new issue or ticket be opend? How is that done and
> how to attach code to it?
>
> Thanks in advance.
>
> best regards
> benjamin
>
> Martijn Dashorst schrieb:
> > Benjamin, Thomas,
> >
> > First of all, thank you for your contributions and continued support
> > for this project. Contrary to what Rainer has stated, your code can
> > become part of Empire-db, and you can become committers, though not
> > immediately. Let me describe these two things in more detail. First
> > concerning your code.
> >
> > If you wish to submit your code for inclusion in the Empire-db
> > project, you should attach the code to a JIRA ticket
> > (http://issues.apache.org/jira/browse/EMPIREDB) and make sure you
> > specify that you intend to have the code be included in Apache
> > software. It would be even better if you would sign and submit a
> > Contributor License Agreement (CLA), specifying that you license the
> > code you commit (or have others commit) to the Apache Software
> > Foundation.
> >
> > Read [1] for more information about the need for CLAs and for
> > instructions on how to send one in, see [2] for the text version of
> > the CLA and [3] for the PDF version. If you have questions concerning
> > CLAs don't hesitate to ask.
> >
> > Once the code is in JIRA, and have the appropriate licensing in place
> > (either the checkbox or a CLA on file), the Empire-db committers can
> > include the code in the project.
> >
> > Now on becoming a committer.
> >
> > You are encouraged to continue to work on the code (of dbgenerator
> > *and* the whole of empire-db!). You should ensure that your code
> style
> > and formatting follows the guidelines set forward by the Empire-db
> > project. If you have changes, please submit a patch with your changes
> > (unified diff works best with Eclipse and svn). The Empire-db
> > committers will evaluate the patch, perhaps suggest improvements, and
> > soon apply it to the code base. You are welcome to submit patches for
> > anything in the project (not limited to the generator code).
> >
> > When your patches are plentiful, and can be applied easily, the
> > Empire-db project members can elect to grant you direct access to the
> > code repository. Usually this happens when they get tired of applying
> > your patches, and want you to do the work yourself. The idea is that
> > people who have shown a continued interest in the project and are
> > actively involved [writing code (*)] should be rewarded with
> > committership. This is at the core of how the ASF works: a
> meritocracy
> > [4,5].
> >
> > (*) there are also Committers who don't write code, but gaining merit
> > for non-coders is usually more difficult than for coders
> >
> > If you have any questions, please let me know.
> >
> > Martijn
> >
> > [1] About Contributor License Agreements:
> http://www.apache.org/licenses/#clas
> > [2] The CLA (text): http://www.apache.org/licenses/icla.txt
> > [3] The CLA (PDF): http://www.apache.org/licenses/icla.pdf
> > [4] About Meritocracy:
> > http://www.apache.org/foundation/how-it-works.html#meritocracy
> > [5] About contributing:
> http://www.apache.org/foundation/getinvolved.html
> >
Re: suggestions for improving Thomas' DBGenerataor
Posted by Francis De Brabandere <fr...@gmail.com>.
You can just create an issue and attach stuff to it afterwards.
If the rc5 release fails once again I suggest we make a 2.0.5 branch
and incorporate the generator code to trunk as an extra maven module.
Cheers,
Francis
ps: You guys can also vote in the vote thread for rc5 if you think it's ok.
On Wed, Sep 9, 2009 at 12:15 PM, Benjamin Venditti<be...@web.de> wrote:
> Hi there,
>
> thank you martijn for the detailed information. In fact i have already
> signed and sent a CLA a few months ago.
> I just signed up at Empire-db on JIRA and tried to figure out how attach
> code to a jira ticket. However i couldn't #
> find the tickets you mentioned, I just found the issues that are reported
> but couldn't find a way how to attach code to one of them.
>
> Should therefore a new issue or ticket be opend? How is that done and how to
> attach code to it?
>
> Thanks in advance.
>
> best regards
> benjamin
>
> Martijn Dashorst schrieb:
>>
>> Benjamin, Thomas,
>>
>> First of all, thank you for your contributions and continued support
>> for this project. Contrary to what Rainer has stated, your code can
>> become part of Empire-db, and you can become committers, though not
>> immediately. Let me describe these two things in more detail. First
>> concerning your code.
>>
>> If you wish to submit your code for inclusion in the Empire-db
>> project, you should attach the code to a JIRA ticket
>> (http://issues.apache.org/jira/browse/EMPIREDB) and make sure you
>> specify that you intend to have the code be included in Apache
>> software. It would be even better if you would sign and submit a
>> Contributor License Agreement (CLA), specifying that you license the
>> code you commit (or have others commit) to the Apache Software
>> Foundation.
>>
>> Read [1] for more information about the need for CLAs and for
>> instructions on how to send one in, see [2] for the text version of
>> the CLA and [3] for the PDF version. If you have questions concerning
>> CLAs don't hesitate to ask.
>>
>> Once the code is in JIRA, and have the appropriate licensing in place
>> (either the checkbox or a CLA on file), the Empire-db committers can
>> include the code in the project.
>>
>> Now on becoming a committer.
>>
>> You are encouraged to continue to work on the code (of dbgenerator
>> *and* the whole of empire-db!). You should ensure that your code style
>> and formatting follows the guidelines set forward by the Empire-db
>> project. If you have changes, please submit a patch with your changes
>> (unified diff works best with Eclipse and svn). The Empire-db
>> committers will evaluate the patch, perhaps suggest improvements, and
>> soon apply it to the code base. You are welcome to submit patches for
>> anything in the project (not limited to the generator code).
>>
>> When your patches are plentiful, and can be applied easily, the
>> Empire-db project members can elect to grant you direct access to the
>> code repository. Usually this happens when they get tired of applying
>> your patches, and want you to do the work yourself. The idea is that
>> people who have shown a continued interest in the project and are
>> actively involved [writing code (*)] should be rewarded with
>> committership. This is at the core of how the ASF works: a meritocracy
>> [4,5].
>>
>> (*) there are also Committers who don't write code, but gaining merit
>> for non-coders is usually more difficult than for coders
>>
>> If you have any questions, please let me know.
>>
>> Martijn
>>
>> [1] About Contributor License Agreements:
>> http://www.apache.org/licenses/#clas
>> [2] The CLA (text): http://www.apache.org/licenses/icla.txt
>> [3] The CLA (PDF): http://www.apache.org/licenses/icla.pdf
>> [4] About Meritocracy:
>> http://www.apache.org/foundation/how-it-works.html#meritocracy
>> [5] About contributing: http://www.apache.org/foundation/getinvolved.html
>>
>
>
--
http://www.somatik.be
Microsoft gives you windows, Linux gives you the whole house.
Re: suggestions for improving Thomas' DBGenerataor
Posted by Benjamin Venditti <be...@web.de>.
Hi there,
thank you martijn for the detailed information. In fact i have already
signed and sent a CLA a few months ago.
I just signed up at Empire-db on JIRA and tried to figure out how attach
code to a jira ticket. However i couldn't #
find the tickets you mentioned, I just found the issues that are
reported but couldn't find a way how to attach code to one of them.
Should therefore a new issue or ticket be opend? How is that done and
how to attach code to it?
Thanks in advance.
best regards
benjamin
Martijn Dashorst schrieb:
> Benjamin, Thomas,
>
> First of all, thank you for your contributions and continued support
> for this project. Contrary to what Rainer has stated, your code can
> become part of Empire-db, and you can become committers, though not
> immediately. Let me describe these two things in more detail. First
> concerning your code.
>
> If you wish to submit your code for inclusion in the Empire-db
> project, you should attach the code to a JIRA ticket
> (http://issues.apache.org/jira/browse/EMPIREDB) and make sure you
> specify that you intend to have the code be included in Apache
> software. It would be even better if you would sign and submit a
> Contributor License Agreement (CLA), specifying that you license the
> code you commit (or have others commit) to the Apache Software
> Foundation.
>
> Read [1] for more information about the need for CLAs and for
> instructions on how to send one in, see [2] for the text version of
> the CLA and [3] for the PDF version. If you have questions concerning
> CLAs don't hesitate to ask.
>
> Once the code is in JIRA, and have the appropriate licensing in place
> (either the checkbox or a CLA on file), the Empire-db committers can
> include the code in the project.
>
> Now on becoming a committer.
>
> You are encouraged to continue to work on the code (of dbgenerator
> *and* the whole of empire-db!). You should ensure that your code style
> and formatting follows the guidelines set forward by the Empire-db
> project. If you have changes, please submit a patch with your changes
> (unified diff works best with Eclipse and svn). The Empire-db
> committers will evaluate the patch, perhaps suggest improvements, and
> soon apply it to the code base. You are welcome to submit patches for
> anything in the project (not limited to the generator code).
>
> When your patches are plentiful, and can be applied easily, the
> Empire-db project members can elect to grant you direct access to the
> code repository. Usually this happens when they get tired of applying
> your patches, and want you to do the work yourself. The idea is that
> people who have shown a continued interest in the project and are
> actively involved [writing code (*)] should be rewarded with
> committership. This is at the core of how the ASF works: a meritocracy
> [4,5].
>
> (*) there are also Committers who don't write code, but gaining merit
> for non-coders is usually more difficult than for coders
>
> If you have any questions, please let me know.
>
> Martijn
>
> [1] About Contributor License Agreements: http://www.apache.org/licenses/#clas
> [2] The CLA (text): http://www.apache.org/licenses/icla.txt
> [3] The CLA (PDF): http://www.apache.org/licenses/icla.pdf
> [4] About Meritocracy:
> http://www.apache.org/foundation/how-it-works.html#meritocracy
> [5] About contributing: http://www.apache.org/foundation/getinvolved.html
>
Re: suggestions for improving Thomas' DBGenerataor
Posted by Martijn Dashorst <ma...@gmail.com>.
Benjamin, Thomas,
First of all, thank you for your contributions and continued support
for this project. Contrary to what Rainer has stated, your code can
become part of Empire-db, and you can become committers, though not
immediately. Let me describe these two things in more detail. First
concerning your code.
If you wish to submit your code for inclusion in the Empire-db
project, you should attach the code to a JIRA ticket
(http://issues.apache.org/jira/browse/EMPIREDB) and make sure you
specify that you intend to have the code be included in Apache
software. It would be even better if you would sign and submit a
Contributor License Agreement (CLA), specifying that you license the
code you commit (or have others commit) to the Apache Software
Foundation.
Read [1] for more information about the need for CLAs and for
instructions on how to send one in, see [2] for the text version of
the CLA and [3] for the PDF version. If you have questions concerning
CLAs don't hesitate to ask.
Once the code is in JIRA, and have the appropriate licensing in place
(either the checkbox or a CLA on file), the Empire-db committers can
include the code in the project.
Now on becoming a committer.
You are encouraged to continue to work on the code (of dbgenerator
*and* the whole of empire-db!). You should ensure that your code style
and formatting follows the guidelines set forward by the Empire-db
project. If you have changes, please submit a patch with your changes
(unified diff works best with Eclipse and svn). The Empire-db
committers will evaluate the patch, perhaps suggest improvements, and
soon apply it to the code base. You are welcome to submit patches for
anything in the project (not limited to the generator code).
When your patches are plentiful, and can be applied easily, the
Empire-db project members can elect to grant you direct access to the
code repository. Usually this happens when they get tired of applying
your patches, and want you to do the work yourself. The idea is that
people who have shown a continued interest in the project and are
actively involved [writing code (*)] should be rewarded with
committership. This is at the core of how the ASF works: a meritocracy
[4,5].
(*) there are also Committers who don't write code, but gaining merit
for non-coders is usually more difficult than for coders
If you have any questions, please let me know.
Martijn
[1] About Contributor License Agreements: http://www.apache.org/licenses/#clas
[2] The CLA (text): http://www.apache.org/licenses/icla.txt
[3] The CLA (PDF): http://www.apache.org/licenses/icla.pdf
[4] About Meritocracy:
http://www.apache.org/foundation/how-it-works.html#meritocracy
[5] About contributing: http://www.apache.org/foundation/getinvolved.html
Re: suggestions for improving Thomas' DBGenerataor
Posted by Francis De Brabandere <fr...@gmail.com>.
Hi all,
We are still discussing on the matter so don't think it won't happen.
Apache works with a 'merit' system to let people in, this to make sure
that we have active committers.
I'm sure we will find a solution you guys agree with.
Cheers,
Francis
On Tue, Sep 8, 2009 at 6:25 PM, Rainer Döbele<do...@esteam.de> wrote:
> Hi Thomas,
>
> glad to hear that you are back and I appreciate very much that you are willing to contribute to our project.
>
> Unfortunately it's not as easy as I hoped it would be. I was hoping that you and Benjamin could become committers of our project and that you would get write access to our SVN this way. Then we could have started a new sub-project for the DBGenerator with you, Benjamin and other committer working together.
>
> Sadly my proposal to do it this way was rejected by our mentors since they demand that potential new committers must prove their interest in the project by submitting several patches over the period of a year or more before they can become committers. Since we're also not allowed to just take over your code without written permission things are going to be difficult.
>
> So at the moment I don't see any chance that we could benefit from your work.
> All we could do at the moment is take your ideas and implement it ourselves - which in my opinion would not be fair. Not even sure it would be legal.
> This is sad but so are the rules.
>
> Sorry that I don't have better news. But I will try to find out if there is another option and let you know.
> Regards
>
> Rainer
>
>
> Thomas Poling wrote:
>> Re: suggestions for improving Thomas' DBGenerataor
>>
>> Greetings All:
>> I was on business travel last week so I'm just catching up on the
>> emails.
>> I agree with almost all the changes suggested - I like the idea of
>> getting
>> rid of the DB connection specifics and keeping it simple by removing
>> all the
>> interfaces and finder methods. As people use it we can add commonly
>> suggested features later. The only part I'd like to keep are the
>> access
>> method for simple attributes because this keeps my hand-generated code
>> a
>> little shorter.
>>
>> Many thanks for making the EmpireDB driver configurable and for
>> Mavenizing
>> the project. I guess that now would be a good time to learn Maven :)
>>
>> I would like to merge all the changes and then maybe put it into the
>> svn
>> repository. Or should we first put the code into the svn repository
>> and
>> then merge in the changes?
>>
>> Thanks, Tom
>
>
--
http://www.somatik.be
Microsoft gives you windows, Linux gives you the whole house.
re: suggestions for improving Thomas' DBGenerataor
Posted by Rainer Döbele <do...@esteam.de>.
Hi Thomas,
glad to hear that you are back and I appreciate very much that you are willing to contribute to our project.
Unfortunately it's not as easy as I hoped it would be. I was hoping that you and Benjamin could become committers of our project and that you would get write access to our SVN this way. Then we could have started a new sub-project for the DBGenerator with you, Benjamin and other committer working together.
Sadly my proposal to do it this way was rejected by our mentors since they demand that potential new committers must prove their interest in the project by submitting several patches over the period of a year or more before they can become committers. Since we're also not allowed to just take over your code without written permission things are going to be difficult.
So at the moment I don't see any chance that we could benefit from your work.
All we could do at the moment is take your ideas and implement it ourselves - which in my opinion would not be fair. Not even sure it would be legal.
This is sad but so are the rules.
Sorry that I don't have better news. But I will try to find out if there is another option and let you know.
Regards
Rainer
Thomas Poling wrote:
> Re: suggestions for improving Thomas' DBGenerataor
>
> Greetings All:
> I was on business travel last week so I'm just catching up on the
> emails.
> I agree with almost all the changes suggested - I like the idea of
> getting
> rid of the DB connection specifics and keeping it simple by removing
> all the
> interfaces and finder methods. As people use it we can add commonly
> suggested features later. The only part I'd like to keep are the
> access
> method for simple attributes because this keeps my hand-generated code
> a
> little shorter.
>
> Many thanks for making the EmpireDB driver configurable and for
> Mavenizing
> the project. I guess that now would be a good time to learn Maven :)
>
> I would like to merge all the changes and then maybe put it into the
> svn
> repository. Or should we first put the code into the svn repository
> and
> then merge in the changes?
>
> Thanks, Tom
Re: suggestions for improving Thomas' DBGenerataor
Posted by Thomas Poling <sn...@comcast.net>.
Greetings All:
I was on business travel last week so I'm just catching up on the emails.
I agree with almost all the changes suggested - I like the idea of getting
rid of the DB connection specifics and keeping it simple by removing all the
interfaces and finder methods. As people use it we can add commonly
suggested features later. The only part I'd like to keep are the access
method for simple attributes because this keeps my hand-generated code a
little shorter.
Many thanks for making the EmpireDB driver configurable and for Mavenizing
the project. I guess that now would be a good time to learn Maven :)
I would like to merge all the changes and then maybe put it into the svn
repository. Or should we first put the code into the svn repository and
then merge in the changes?
Thanks, Tom
re: suggestions for improving Thomas' DBGenerataor
Posted by Rainer Döbele <do...@esteam.de>.
Francis De Brabandere wrote:
> Re: suggestions for improving Thomas' DBGenerataor
>
> Hi all,
>
> Just to let you guys have my support on this generator. I really hope
> we can get our current release out and that we can have this generator
> as the next big feature for the next release.
+1
Rainer
>
> Cheers,
> Francis
>
re: suggestions for improving Thomas' DBGenerataor
Posted by Rainer Döbele <do...@esteam.de>.
Francis De Brabandere wrote:
> Re: suggestions for improving Thomas' DBGenerataor
>
> Hi all,
>
> Just to let you guys have my support on this generator. I really hope
> we can get our current release out and that we can have this generator
> as the next big feature for the next release.
+1
Rainer
>
> Cheers,
> Francis
>
Re: suggestions for improving Thomas' DBGenerataor
Posted by Francis De Brabandere <fr...@gmail.com>.
Hi all,
Just to let you guys have my support on this generator. I really hope
we can get our current release out and that we can have this generator
as the next big feature for the next release.
Cheers,
Francis
On Mon, Sep 7, 2009 at 5:13 PM, Benjamin Venditti<be...@web.de> wrote:
> Hi Rainer & Thomas
>
> i'm currently a little busy as i'm moving to vienna this month, but i
> haven't forgotten DBGenerator ;-) .
>
> I agree with the most of rainer's suggestions:
>
> 1. A database class needs no connection stuff inside. --> So the database
> will get configured via the constuctor.
> 2. A empty (for the beginning) in between table class named XXXTable (XXX
> is a userdefined prefix), so the user (developer) may add methods there.
> 3. Just put the basics to a individual record class, so no
> locking/attribute getters or relationship finders.
> 4. The common XXXRecord (XXX is a userdefined prefix) class should utilize
> generics.
>
> I hope i got it right so far.
>
> Thomas, what do you think about these changes?
>
> best regards,
> benjamin
>
> Rainer Döbele schrieb:
>>
>> Hi Thomas, Hi Benni,
>>
>> finally I found the time to take a closer look at the DBGenerataor and
>> what you are doing there looks very promising already.
>>
>> So far most conversation has been on the empire-db-user mailing list. I
>> would recommend moving it to the empire-db-dev mailing list. I am not sure,
>> whether Thomas is subscribed to this list and if he has received Benjamin's
>> last message (see below).
>>
>> At the moment the database connection is hard-coded in
>> DbCodeGenerator::main which is obviously not a good idea but should be easy
>> to fix. Thanks Benni for mavenizing the project - Thomas are you happy with
>> that?
>>
>> As far as the generated code is concerned we should first decide what is
>> absolutely necessary and what are individual extensions that possibly could
>> be added manually later. I for example do not find the necessity to generate
>> the interfaces IRecord and IBaseRecord (besides the "I"- prefix is not
>> commonly used in Java). Once the Record class has been generated e.g. anyone
>> can manually extend it and generate an interface for the class.
>>
>> What I would recommend to generate is the following:
>>
>> - The database class, but only with the definition and without all the
>> connection stuff. A database may be used in more than one instance with
>> different connections and thus it's not necessarily a singleton.
>>
>> - A base table class that goes between DBTable and the actual individual
>> table classes. The name should be configurable (if it is XXXDatabase it
>> should be XXXTable). This class can be empty at first so that the user can
>> add methods there. I always create such an in-between table class in my
>> projects and I use it for auto-setting fields like user-names or
>> create-timestamps. It's very convenient.
>>
>> - The individual table classes, possibly with an option to generate top
>> level classes (individual files) or to create them as nested classes inside
>> the database class (if this is possible).
>>
>> - A base record class as you have done, but the class signature should be
>> as follows:
>>
>> public class XXXRecord<T extends XXXTable> extends DBRecord
>>
>> Using generics here brings a real advantage, as the base record class can
>> then use properties and methods of the base table class.
>>
>> - The individual record classes. Personally I don't like and need the
>> access methods for simple attributes and the finder methods (they make it
>> look like OR-Mapper beans and people may use them like that). The purpose of
>> these classes should be mainly to override methods like getFieldOptions,
>> update and delete.
>>
>> These are my suggestions. I would appreciate if you would be willing to
>> work with us any possibly donate your code to the ASF so that we can supply
>> it with a future release of Empire-db. In this case we could add the code to
>> our svn repository so that you can all conveniently work on it.
>>
>> What do you think?
>>
>> Regards,
>> Rainer
>>
>>
>> Benniven wrote:
>>
>>>
>>> re: automatic empire-db driver configuration | mavenizing
>>>
>>> Hi there,
>>>
>>> i added the code to the Database.vm template so that it can
>>> automatically configure the desired EmpireDB driver.
>>> I used jetty's XMLConfiguration class to do that. I also mavenized the
>>> project, so that it is easier to get it running.
>>> Please let me know what you think of it.
>>>
>>> Modified files:
>>> Database.vm
>>> Database.java
>>> DbCodeGenerator.java
>>>
>>> New files:
>>> database-configuration.xml
>>> pom.xml
>>>
>>> thanks in advance
>>> benni
>>>
>>> WARNING:
>>> I currently use HSQL for testing. I therefore had to modify all the
>>> database meta-data retrieving code in the file Table.java.
>>> e.g. the line:
>>> ResultSet fkRs = dbMeta.getImportedKeys(schema, null ,
>>> tableName);
>>> was changed to:
>>> ResultSet fkRs = dbMeta.getImportedKeys(null, schema,
>>> tableName);
>>>
>
>
--
http://www.somatik.be
Microsoft gives you windows, Linux gives you the whole house.
Re: suggestions for improving Thomas' DBGenerataor
Posted by Francis De Brabandere <fr...@gmail.com>.
Hi all,
Just to let you guys have my support on this generator. I really hope
we can get our current release out and that we can have this generator
as the next big feature for the next release.
Cheers,
Francis
On Mon, Sep 7, 2009 at 5:13 PM, Benjamin Venditti<be...@web.de> wrote:
> Hi Rainer & Thomas
>
> i'm currently a little busy as i'm moving to vienna this month, but i
> haven't forgotten DBGenerator ;-) .
>
> I agree with the most of rainer's suggestions:
>
> 1. A database class needs no connection stuff inside. --> So the database
> will get configured via the constuctor.
> 2. A empty (for the beginning) in between table class named XXXTable (XXX
> is a userdefined prefix), so the user (developer) may add methods there.
> 3. Just put the basics to a individual record class, so no
> locking/attribute getters or relationship finders.
> 4. The common XXXRecord (XXX is a userdefined prefix) class should utilize
> generics.
>
> I hope i got it right so far.
>
> Thomas, what do you think about these changes?
>
> best regards,
> benjamin
>
> Rainer Döbele schrieb:
>>
>> Hi Thomas, Hi Benni,
>>
>> finally I found the time to take a closer look at the DBGenerataor and
>> what you are doing there looks very promising already.
>>
>> So far most conversation has been on the empire-db-user mailing list. I
>> would recommend moving it to the empire-db-dev mailing list. I am not sure,
>> whether Thomas is subscribed to this list and if he has received Benjamin's
>> last message (see below).
>>
>> At the moment the database connection is hard-coded in
>> DbCodeGenerator::main which is obviously not a good idea but should be easy
>> to fix. Thanks Benni for mavenizing the project - Thomas are you happy with
>> that?
>>
>> As far as the generated code is concerned we should first decide what is
>> absolutely necessary and what are individual extensions that possibly could
>> be added manually later. I for example do not find the necessity to generate
>> the interfaces IRecord and IBaseRecord (besides the "I"- prefix is not
>> commonly used in Java). Once the Record class has been generated e.g. anyone
>> can manually extend it and generate an interface for the class.
>>
>> What I would recommend to generate is the following:
>>
>> - The database class, but only with the definition and without all the
>> connection stuff. A database may be used in more than one instance with
>> different connections and thus it's not necessarily a singleton.
>>
>> - A base table class that goes between DBTable and the actual individual
>> table classes. The name should be configurable (if it is XXXDatabase it
>> should be XXXTable). This class can be empty at first so that the user can
>> add methods there. I always create such an in-between table class in my
>> projects and I use it for auto-setting fields like user-names or
>> create-timestamps. It's very convenient.
>>
>> - The individual table classes, possibly with an option to generate top
>> level classes (individual files) or to create them as nested classes inside
>> the database class (if this is possible).
>>
>> - A base record class as you have done, but the class signature should be
>> as follows:
>>
>> public class XXXRecord<T extends XXXTable> extends DBRecord
>>
>> Using generics here brings a real advantage, as the base record class can
>> then use properties and methods of the base table class.
>>
>> - The individual record classes. Personally I don't like and need the
>> access methods for simple attributes and the finder methods (they make it
>> look like OR-Mapper beans and people may use them like that). The purpose of
>> these classes should be mainly to override methods like getFieldOptions,
>> update and delete.
>>
>> These are my suggestions. I would appreciate if you would be willing to
>> work with us any possibly donate your code to the ASF so that we can supply
>> it with a future release of Empire-db. In this case we could add the code to
>> our svn repository so that you can all conveniently work on it.
>>
>> What do you think?
>>
>> Regards,
>> Rainer
>>
>>
>> Benniven wrote:
>>
>>>
>>> re: automatic empire-db driver configuration | mavenizing
>>>
>>> Hi there,
>>>
>>> i added the code to the Database.vm template so that it can
>>> automatically configure the desired EmpireDB driver.
>>> I used jetty's XMLConfiguration class to do that. I also mavenized the
>>> project, so that it is easier to get it running.
>>> Please let me know what you think of it.
>>>
>>> Modified files:
>>> Database.vm
>>> Database.java
>>> DbCodeGenerator.java
>>>
>>> New files:
>>> database-configuration.xml
>>> pom.xml
>>>
>>> thanks in advance
>>> benni
>>>
>>> WARNING:
>>> I currently use HSQL for testing. I therefore had to modify all the
>>> database meta-data retrieving code in the file Table.java.
>>> e.g. the line:
>>> ResultSet fkRs = dbMeta.getImportedKeys(schema, null ,
>>> tableName);
>>> was changed to:
>>> ResultSet fkRs = dbMeta.getImportedKeys(null, schema,
>>> tableName);
>>>
>
>
--
http://www.somatik.be
Microsoft gives you windows, Linux gives you the whole house.