You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Juozas Baliuka <ba...@mail.lt> on 2003/03/05 19:46:41 UTC
[dbutils] Proxies
I remember we decided not to implement religion in dbutils, but we can try
this kind of experiment :
interface MyProcedure {
int executeSomeQuery( int p1, String p2 );
}
static final MyProcedure PROC1 = DbUtils.newInstance( MyProcedure.class,
sql,
new ResultSetHandlerImpl()
);
//use it this way (connection is in ThreadLocal )
DbUtils.setConnection(connection);
in a = PROC1.executeSomeQuery(1,"test");
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[dbutils]Dependancy on QDox was Re: [dbutils] Proxies
Posted by Juozas Baliuka <ba...@centras.lt>.
I have started implementation for this stuff, it depends on QDox ( javadoc
parser ),
I need some metada to implement sql procedure call, java sourse file is
used as metadata itself:
<code>
interface MyDAO{
/**
* @sql SELECT * FROM MY_TABLE
* @handler com.maycompany.MyHandler
*/
Collection getAll();
/**
* @sql SELECT MAX(VALUE) FROM MY_TABLE WHERE VALUE < $1
*
*/
int getMaxLesThan(int p1);
/**
* @sql SELECT COUNT(*) FROM MY_TABLE WHERE VALUE < $1 and VALUE >= $2
*/
int getCount(int p1, int p2);
/**
* @sql UPDATE MY_TABLE SET VALUE=$1
* @handler update
*/
void setValue(int value);
}
}
public class Main{
public static main( String args[] ){
Connection connection = getConnection();
try{
MyDAO dao = ( MyDAO)ProcedureUtils.getInstance(MyDAO.class, connection );
dao.setValue( dao.getCount(200, getMaxLesThan(1)) );
connection.commit();
}finaly{
connection.close();
}
}
</code>
QDox is used to parse metada at runtime, implementation is generated at
runtime too (java.lang.reflect.Proxy),
XML free code, no custom build tools and reinvented QL.
Is it not out of dbutils scope ?
----- Original Message -----
From: "Henri Yandell" <ba...@generationjava.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Thursday, March 06, 2003 3:35 AM
Subject: Re: [dbutils] Proxies
>
> Seems okay to me. Though I think religious things should probably be in
> their own Class namespace rather than the central DbUtils namespace.
>
> So: ProcedureUtils, or even procedure.ProcedureUtils.
>
> DbUtils can use these invisibly [as it currently uses ResultSetHandler via
> anonymous classes and private methods] but would never offer up any type
> from a sub-package/religion.
>
> Looking a bit further, the only bit I dislike is the
> DbUtils.setConnection(conn). In my view this should be an explicit
> instance, so [ignoring the namespace issues] you'd do:
>
> DbUtils dbutils = DbUtils.getInstance();
> dbutils.setConnection(conn);
> dbutils.doThing(); // etc
>
> Though I'm not sure you didn't mean to do that anyway :)
>
> Hen
>
> On Wed, 5 Mar 2003, Juozas Baliuka wrote:
>
> > I remember we decided not to implement religion in dbutils, but we can
try
> > this kind of experiment :
> >
> > interface MyProcedure {
> >
> > int executeSomeQuery( int p1, String p2 );
> >
> > }
> >
> > static final MyProcedure PROC1 = DbUtils.newInstance(
MyProcedure.class,
> >
> > sql,
> >
> > new ResultSetHandlerImpl()
> >
> > );
> >
> > //use it this way (connection is in ThreadLocal )
> > DbUtils.setConnection(connection);
> > in a = PROC1.executeSomeQuery(1,"test");
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [dbutils] Proxies
Posted by Juozas Baliuka <ba...@centras.lt>.
I have added this stuff,
but possible it is better to have some new experimental project dependant on
dbutils and attributes.
I want to implement somethin like this :
interface MyDAO{
@sql SELECT MAX(VALUE) FROM MY_TABLE WHERE VALUE < $1
int getMaxLesThan(int p1);
@sql SELECT COUNT(*) FROM MY_TABLE WHERE VALUE < $1 and VALUE >= $2
int getCount(int p1, int p2);
}
MyDAO dao (MyDAO)=ProcedurUtils.newInstance(MyDAO.class);
----- Original Message -----
From: "Henri Yandell" <ba...@generationjava.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Thursday, March 06, 2003 3:35 AM
Subject: Re: [dbutils] Proxies
>
> Seems okay to me. Though I think religious things should probably be in
> their own Class namespace rather than the central DbUtils namespace.
>
> So: ProcedureUtils, or even procedure.ProcedureUtils.
>
> DbUtils can use these invisibly [as it currently uses ResultSetHandler via
> anonymous classes and private methods] but would never offer up any type
> from a sub-package/religion.
>
> Looking a bit further, the only bit I dislike is the
> DbUtils.setConnection(conn). In my view this should be an explicit
> instance, so [ignoring the namespace issues] you'd do:
>
> DbUtils dbutils = DbUtils.getInstance();
> dbutils.setConnection(conn);
> dbutils.doThing(); // etc
>
> Though I'm not sure you didn't mean to do that anyway :)
>
> Hen
>
> On Wed, 5 Mar 2003, Juozas Baliuka wrote:
>
> > I remember we decided not to implement religion in dbutils, but we can
try
> > this kind of experiment :
> >
> > interface MyProcedure {
> >
> > int executeSomeQuery( int p1, String p2 );
> >
> > }
> >
> > static final MyProcedure PROC1 = DbUtils.newInstance(
MyProcedure.class,
> >
> > sql,
> >
> > new ResultSetHandlerImpl()
> >
> > );
> >
> > //use it this way (connection is in ThreadLocal )
> > DbUtils.setConnection(connection);
> > in a = PROC1.executeSomeQuery(1,"test");
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [dbutils] Proxies
Posted by Henri Yandell <ba...@generationjava.com>.
Seems okay to me. Though I think religious things should probably be in
their own Class namespace rather than the central DbUtils namespace.
So: ProcedureUtils, or even procedure.ProcedureUtils.
DbUtils can use these invisibly [as it currently uses ResultSetHandler via
anonymous classes and private methods] but would never offer up any type
from a sub-package/religion.
Looking a bit further, the only bit I dislike is the
DbUtils.setConnection(conn). In my view this should be an explicit
instance, so [ignoring the namespace issues] you'd do:
DbUtils dbutils = DbUtils.getInstance();
dbutils.setConnection(conn);
dbutils.doThing(); // etc
Though I'm not sure you didn't mean to do that anyway :)
Hen
On Wed, 5 Mar 2003, Juozas Baliuka wrote:
> I remember we decided not to implement religion in dbutils, but we can try
> this kind of experiment :
>
> interface MyProcedure {
>
> int executeSomeQuery( int p1, String p2 );
>
> }
>
> static final MyProcedure PROC1 = DbUtils.newInstance( MyProcedure.class,
>
> sql,
>
> new ResultSetHandlerImpl()
>
> );
>
> //use it this way (connection is in ThreadLocal )
> DbUtils.setConnection(connection);
> in a = PROC1.executeSomeQuery(1,"test");
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org