You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@gump.apache.org by Ceki Gülcü <no...@qos.ch> on 2004/05/15 15:46:16 UTC

Existence of a database?

Hello,

In log4j we have components which write or read from a DB with accompanying 
test cases. Could we assume that gump machines have a database that these 
test cases can connect to?

I am just curious...


-- 
Ceki Gülcü

      For log4j documentation consider "The complete log4j manual"
      ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp  



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Re: Existence of a database?

Posted by Davanum Srinivas <da...@gmail.com>.
Ceki,

i'd embed say Axion or HSQLDB into the build process. There is no
guarantee about either existence of a DB and params are going to be
machine/db specific anyways.

-- dims

On Sat, 15 May 2004 15:46:16 +0200, Ceki Gülcü <no...@qos.ch> wrote:
> 
> 
> Hello,
> 
> In log4j we have components which write or read from a DB with accompanying
> test cases. Could we assume that gump machines have a database that these
> test cases can connect to?
> 
> I am just curious...
> 
> --
> Ceki Gülcü
> 
>       For log4j documentation consider "The complete log4j manual"
>       ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Re: Existence of a database?

Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 19 May 2004, Ceki Gülc <ce...@qos.ch> wrote:

> I wonder if it possible to group tasks and invoke them as a function
> or a method call.

Rather "as a macro".  Let me see whether I can find a macrodef
solution for you.

The target running the test would be easy:

<macrodef name="rundbtest">
  <attribute name="dbtype"/>
  <sequential>
    <delete file="./input/db/db.properties"/>
    <echo message="@{dbtype} available"/>
    <copy file="./input/db/@{dbtype}.properties" 
          tofile="./input/db/db.properties"/>

    <junit printsummary="yes" fork="no" haltonfailure="yes">
      <sysproperty key="runLen" value="100"/>
      <classpath refid="tests.classpath"/>
      <formatter type="plain" usefile="false"/>
      <test name="org.apache.log4j.db.FullCycleDBTest" />
    </junit>
  </sequential>
</macrodef>

and

<target name="mysql" depends="mysqlCheck, build" if="mysql-present">
  <rundbtest dbtype="mysql"/>
</target>
<target name="postgresql" depends="postgresqlCheck, build" 
        if="postgresql-present">
  <rundbtest dbtype="postgresql"/>
</target>

The checking part may be more difficult than the tests you've shown,
you could also <macrodef> them if they really are that similar for all
databases.

The whole check-then-test logic could be streamlined into a single
macro with Ant-Contrib's <if> if you feel that inclined.   A pure Ant
solution would probably look like:

* write a build file that contains check and test targets much like
  your old build file did and use properties for all DB specific things
  (JDBC driver, property file).  No macros, plain old targets.

* for each database you intend to support write a tiny little build
  file that <import>s the build file above and sets the properties.
  If you ever encounter a database that needs more complicated checks
  than the ones you have so far, you can override the check target
  (<import> supports "target inheritance").

* In you master build file, <subant> over your database specific build
  files.

But we are really getting off Gump-topic here 8-)

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Re: Existence of a database?

Posted by Martin van den Bemt <ml...@mvdb.net>.
I was talking ant 1.4 indeed :)

Mvgr,
Martin

On Mon, 2004-05-24 at 09:18, Stefan Bodewig wrote:
> On Wed, 19 May 2004, Martin van den Bemt <ml...@mvdb.net> wrote:
> 
> > Use antcall to call the target with the db specific properties, this
> > way you can merge the postresql and the mysql targets.
> 
> No.  Use Ant 1.6+ and <macrodef>. 8-)
> 
> Stefan
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
-- 
Mvgr,
Martin


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Re: Existence of a database?

Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 19 May 2004, Martin van den Bemt <ml...@mvdb.net> wrote:

> Use antcall to call the target with the db specific properties, this
> way you can merge the postresql and the mysql targets.

No.  Use Ant 1.6+ and <macrodef>. 8-)

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


RE: Existence of a database?

Posted by Martin van den Bemt <ml...@mvdb.net>.
Use antcall to call the target with the db specific properties, this way
you can merge the postresql and the mysql targets. You can eg add a
commandline parameter for the people who eg just want to run the
postgressql target eg ant -Ddbtest=mysql.

Mvgr,
Martin

On Wed, 2004-05-19 at 14:01, Ceki Gülcü wrote:
> Thanks everyone for answering.
> 
> At 01:27 PM 5/19/2004, Eric Pugh wrote:
> >I find that depending on an external database makes the unit tests very
> >brittle..   Unless you are specifically testing something that requires a
> >specific type of database, I find that using hsqldb or axion works fine..
> 
> I agree that having tests run all several databases makes things 
> complicated and brittle. We currently have tests unit tests that work on 
> mysql and postgres. The Junit test case plus the related log4j config files 
> import a DB specific property file at runtime if it is available on the 
> local system, otherwise the test for that db are skipped. Adding tests for 
> other databases should be easy, except that it would result in duplication 
> of targets in the Ant build file.
> 
> The build file is available here:
> 
> http://cvs.apache.org/viewcvs.cgi/logging-log4j/tests/build.xml?rev=1.54
> 
> The relevant part is reproduced below.
> 
>   <!-- ================================================================= -->
>    <!-- ========================= DB Tests ======================= -->
>    <!-- ================================================================= -->
> 
>    <!-- These tests follow the same pattern. They will be run if a property 
> file
>         defining access as well as necessary class files are available. 
> Otherwise,
>         the test is skipped.
>         -->
> 
>    <target name="mysqlCheck">
>      <condition property="mysql-present">
>      <and>
>        <available file="./input/db/mysql.properties" />
>        <available classname="com.mysql.jdbc.Driver">
>          <classpath refid="tests.classpath"/>
>        </available>
>      </and>
>      </condition>
>    </target>
> 
> 
>    <target name="mysql" depends="mysqlCheck, build" if="mysql-present">
> 
>      <delete file="./input/db/db.properties"/>
>      <echo message="MySQL available"/>
>      <copy file="./input/db/mysql.properties" 
> tofile="./input/db/db.properties"/>
> 
>      <junit printsummary="yes" fork="no" haltonfailure="yes">
>        <sysproperty key="runLen" value="100"/>
>        <classpath refid="tests.classpath"/>
>        <formatter type="plain" usefile="false"/>
>        <test name="org.apache.log4j.db.FullCycleDBTest" />
>      </junit>
>    </target>
> 
> 
>    <target name="postgresqlCheck">
>      <condition property="postgresql-present">
>      <and>
>        <available file="./input/db/postgresql.properties" />
>        <available classname="org.postgresql.Driver">
>          <classpath refid="tests.classpath"/>
>        </available>
>      </and>
>      </condition>
>    </target>
> 
>    <target name="postgresql" depends="postgresqlCheck, build" 
> if="postgresql-present">
>      <delete file="./input/db/db.properties"/>
>      <echo message="PostgreSQL available"/>
>      <copy file="./input/db/postgresql.properties" 
> tofile="./input/db/db.properties"/>
> 
>      <junit printsummary="yes" fork="no" haltonfailure="yes">
>        <sysproperty key="runLen" value="100"/>
>        <classpath refid="tests.classpath"/>
>        <formatter type="plain" usefile="false"/>
>        <test name="org.apache.log4j.db.FullCycleDBTest" />
>      </junit>
>    </target>
> 
> 
> 
> As you can see there is almost complete duplication of the tasks for mysql 
> and postgresql. I wonder if it possible to group tasks and invoke them as a 
> function or a method call.
> 
> Anyway, I am digressing. Thanks for your help.
> 
> 
> >Eric
> >
> > > -----Original Message-----
> > > From: Stefan Bodewig [mailto:bodewig@apache.org]
> > > Sent: Wednesday, May 19, 2004 9:24 AM
> > > To: general@gump.apache.org
> > > Subject: Re: Existence of a database?
> > >
> > >
> > > On Sat, 15 May 2004, Ceki Gülc <no...@qos.ch> wrote:
> > >
> > > > Could we assume that gump machines have a database that these test
> > > > cases can connect to?
> > >
> > > You can savely assume that hsqldb is around[1] but not "installed" in
> > > any way.  I.e. you could make your tests depend on hsqldb and they'd
> > > work in Gump.
> > >
> > > Even if some Gump machine may use some kind of DB in the future (to
> > > gather historical data or whatever else we come up with), there'll be
> > > no guarantee that all machines have one.
> > >
> > > Stefan
> > >
> > > Footnotes:
> > > [1]  http://brutus.apache.org/gump/public/hsqldb/hsqldb/index.html
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
> > > For additional commands, e-mail: general-help@gump.apache.org
> > >
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
> >For additional commands, e-mail: general-help@gump.apache.org
-- 
Mvgr,
Martin


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


RE: Existence of a database?

Posted by Ceki Gülcü <ce...@qos.ch>.
Thanks everyone for answering.

At 01:27 PM 5/19/2004, Eric Pugh wrote:
>I find that depending on an external database makes the unit tests very
>brittle..   Unless you are specifically testing something that requires a
>specific type of database, I find that using hsqldb or axion works fine..

I agree that having tests run all several databases makes things 
complicated and brittle. We currently have tests unit tests that work on 
mysql and postgres. The Junit test case plus the related log4j config files 
import a DB specific property file at runtime if it is available on the 
local system, otherwise the test for that db are skipped. Adding tests for 
other databases should be easy, except that it would result in duplication 
of targets in the Ant build file.

The build file is available here:

http://cvs.apache.org/viewcvs.cgi/logging-log4j/tests/build.xml?rev=1.54

The relevant part is reproduced below.

  <!-- ================================================================= -->
   <!-- ========================= DB Tests ======================= -->
   <!-- ================================================================= -->

   <!-- These tests follow the same pattern. They will be run if a property 
file
        defining access as well as necessary class files are available. 
Otherwise,
        the test is skipped.
        -->

   <target name="mysqlCheck">
     <condition property="mysql-present">
     <and>
       <available file="./input/db/mysql.properties" />
       <available classname="com.mysql.jdbc.Driver">
         <classpath refid="tests.classpath"/>
       </available>
     </and>
     </condition>
   </target>


   <target name="mysql" depends="mysqlCheck, build" if="mysql-present">

     <delete file="./input/db/db.properties"/>
     <echo message="MySQL available"/>
     <copy file="./input/db/mysql.properties" 
tofile="./input/db/db.properties"/>

     <junit printsummary="yes" fork="no" haltonfailure="yes">
       <sysproperty key="runLen" value="100"/>
       <classpath refid="tests.classpath"/>
       <formatter type="plain" usefile="false"/>
       <test name="org.apache.log4j.db.FullCycleDBTest" />
     </junit>
   </target>


   <target name="postgresqlCheck">
     <condition property="postgresql-present">
     <and>
       <available file="./input/db/postgresql.properties" />
       <available classname="org.postgresql.Driver">
         <classpath refid="tests.classpath"/>
       </available>
     </and>
     </condition>
   </target>

   <target name="postgresql" depends="postgresqlCheck, build" 
if="postgresql-present">
     <delete file="./input/db/db.properties"/>
     <echo message="PostgreSQL available"/>
     <copy file="./input/db/postgresql.properties" 
tofile="./input/db/db.properties"/>

     <junit printsummary="yes" fork="no" haltonfailure="yes">
       <sysproperty key="runLen" value="100"/>
       <classpath refid="tests.classpath"/>
       <formatter type="plain" usefile="false"/>
       <test name="org.apache.log4j.db.FullCycleDBTest" />
     </junit>
   </target>



As you can see there is almost complete duplication of the tasks for mysql 
and postgresql. I wonder if it possible to group tasks and invoke them as a 
function or a method call.

Anyway, I am digressing. Thanks for your help.


>Eric
>
> > -----Original Message-----
> > From: Stefan Bodewig [mailto:bodewig@apache.org]
> > Sent: Wednesday, May 19, 2004 9:24 AM
> > To: general@gump.apache.org
> > Subject: Re: Existence of a database?
> >
> >
> > On Sat, 15 May 2004, Ceki Gülc <no...@qos.ch> wrote:
> >
> > > Could we assume that gump machines have a database that these test
> > > cases can connect to?
> >
> > You can savely assume that hsqldb is around[1] but not "installed" in
> > any way.  I.e. you could make your tests depend on hsqldb and they'd
> > work in Gump.
> >
> > Even if some Gump machine may use some kind of DB in the future (to
> > gather historical data or whatever else we come up with), there'll be
> > no guarantee that all machines have one.
> >
> > Stefan
> >
> > Footnotes:
> > [1]  http://brutus.apache.org/gump/public/hsqldb/hsqldb/index.html
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
> > For additional commands, e-mail: general-help@gump.apache.org
> >
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
>For additional commands, e-mail: general-help@gump.apache.org

-- 
Ceki Gülcü

      For log4j documentation consider "The complete log4j manual"
      ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp  



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


RE: Existence of a database?

Posted by Eric Pugh <ep...@opensourceconnections.com>.
I find that depending on an external database makes the unit tests very
brittle..   Unless you are specifically testing something that requires a
specific type of database, I find that using hsqldb or axion works fine..

Eric

> -----Original Message-----
> From: Stefan Bodewig [mailto:bodewig@apache.org]
> Sent: Wednesday, May 19, 2004 9:24 AM
> To: general@gump.apache.org
> Subject: Re: Existence of a database?
>
>
> On Sat, 15 May 2004, Ceki Gülc <no...@qos.ch> wrote:
>
> > Could we assume that gump machines have a database that these test
> > cases can connect to?
>
> You can savely assume that hsqldb is around[1] but not "installed" in
> any way.  I.e. you could make your tests depend on hsqldb and they'd
> work in Gump.
>
> Even if some Gump machine may use some kind of DB in the future (to
> gather historical data or whatever else we come up with), there'll be
> no guarantee that all machines have one.
>
> Stefan
>
> Footnotes:
> [1]  http://brutus.apache.org/gump/public/hsqldb/hsqldb/index.html
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Re: Existence of a database?

Posted by Stefan Bodewig <bo...@apache.org>.
On Sat, 15 May 2004, Ceki Gülc <no...@qos.ch> wrote:

> Could we assume that gump machines have a database that these test
> cases can connect to?

You can savely assume that hsqldb is around[1] but not "installed" in
any way.  I.e. you could make your tests depend on hsqldb and they'd
work in Gump.

Even if some Gump machine may use some kind of DB in the future (to
gather historical data or whatever else we come up with), there'll be
no guarantee that all machines have one.

Stefan

Footnotes: 
[1]  http://brutus.apache.org/gump/public/hsqldb/hsqldb/index.html


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org