OT: easiest way to create a custom PreparedStatement class

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

OT: easiest way to create a custom PreparedStatement class

zorchon
I am modifying some existing data loading code (that only makes use of 4
or 5 methods from PreparedStatement) to optionally be able to *not*
connect to a database but instead dump either the generated SQL code or
the raw insert data to files on the file system.

It would be great if I could just overload PreparedStatement with my own
classes, but unfortunately it is an interface, so I presumably need to
implement stubs for the umpty-ump methods defined by PreparedStatement?

Is this true, and if so, what is the easiest/fastest way to do this (if
it is even possible)?

I am a java newbie, by the way.  Don't flame me too hard.  I did say
"OT", after all ;-)

Thanks,
Kevin


---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to [hidden email] so that your
       message can get through to the mailing list cleanly
Reply | Threaded
Open this post in threaded view
|

Re: OT: easiest way to create a custom PreparedStatement class

Craig Servin
Or you could use:

java.lang.reflect.Proxy




On Tuesday 28 June 2005 01:55 pm, Kevin Murphy wrote:

> I am modifying some existing data loading code (that only makes use of 4
> or 5 methods from PreparedStatement) to optionally be able to *not*
> connect to a database but instead dump either the generated SQL code or
> the raw insert data to files on the file system.
>
> It would be great if I could just overload PreparedStatement with my own
> classes, but unfortunately it is an interface, so I presumably need to
> implement stubs for the umpty-ump methods defined by PreparedStatement?
>
> Is this true, and if so, what is the easiest/fastest way to do this (if
> it is even possible)?
>
> I am a java newbie, by the way.  Don't flame me too hard.  I did say
> "OT", after all ;-)
>
> Thanks,
> Kevin
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
>        subscribe-nomail command to [hidden email] so that your
>        message can get through to the mailing list cleanly

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to [hidden email] so that your
       message can get through to the mailing list cleanly
Reply | Threaded
Open this post in threaded view
|

Re: OT: easiest way to create a custom PreparedStatement class

Craig Servin-2
In reply to this post by zorchon
Or you could use:

java.lang.reflect.Proxy


On Tuesday 28 June 2005 01:55 pm, Kevin Murphy wrote:

> I am modifying some existing data loading code (that only makes use of 4
> or 5 methods from PreparedStatement) to optionally be able to *not*
> connect to a database but instead dump either the generated SQL code or
> the raw insert data to files on the file system.
>
> It would be great if I could just overload PreparedStatement with my own
> classes, but unfortunately it is an interface, so I presumably need to
> implement stubs for the umpty-ump methods defined by PreparedStatement?
>
> Is this true, and if so, what is the easiest/fastest way to do this (if
> it is even possible)?
>
> I am a java newbie, by the way.  Don't flame me too hard.  I did say
> "OT", after all ;-)
>
> Thanks,
> Kevin
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
>        subscribe-nomail command to [hidden email] so that your
>        message can get through to the mailing list cleanly

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
Reply | Threaded
Open this post in threaded view
|

Re: OT: easiest way to create a custom PreparedStatement

Mark Lewis
We use java.lang.reflect.Proxy in our production systems to do things like log SQL statements, do a little bookkeeping for application-level replication, log timings and the like.  Works great.

Here's a snippet that we use to wrap a PreparedStatement with a proxy to do some logging every time somebody calls any method on it.

-- Mark Lewis


         final PreparedStatement realStatement = xxx;

        PreparedStatement debugWrapped = (PreparedStatement)Proxy.newProxyInstance(getClass().getClassLoader(), new Class[]{PreparedStatement.class}, new InvocationHandler() {
            public Object invoke(Object instance, Method method, Object [] params) throws Throwable {
            StringBuffer buf = new StringBuffer();
            buf.append("Called ").append(method.getName());
            buf.append('(');
            if(params != null) {
            for(int i=0; i<params.length; i++) {
            if(i > 0) buf.append(',');
            buf.append(String.valueOf(params[i]));
            }
            }
            buf.append(')');
            log.debug(buf);
            try {
            return method.invoke(realStatement, params);
            }
            catch(InvocationTargetException ex) {
            throw ex.getCause();
            }
            }
            });




On Tue, 2005-06-28 at 14:55 -0500, Craig Servin wrote:
Or you could use:

java.lang.reflect.Proxy


On Tuesday 28 June 2005 01:55 pm, Kevin Murphy wrote:
> I am modifying some existing data loading code (that only makes use of 4
> or 5 methods from PreparedStatement) to optionally be able to *not*
> connect to a database but instead dump either the generated SQL code or
> the raw insert data to files on the file system.
>
> It would be great if I could just overload PreparedStatement with my own
> classes, but unfortunately it is an interface, so I presumably need to
> implement stubs for the umpty-ump methods defined by PreparedStatement?
>
> Is this true, and if so, what is the easiest/fastest way to do this (if
> it is even possible)?
>
> I am a java newbie, by the way.  Don't flame me too hard.  I did say
> "OT", after all ;-)
>
> Thanks,
> Kevin
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
>        subscribe-nomail command to [hidden email] so that your
>        message can get through to the mailing list cleanly

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
Reply | Threaded
Open this post in threaded view
|

Wish list

zorchon
In reply to this post by Craig Servin-2
In the context of my current project of writing code that can 1) access
a database directly, 2) write sql statements to a file instead of
executing them, and also, 3) write raw data for insert to flat files:

it would be nice if the JDBC driver could somehow expose the
functionality to do the quoting and escaping required in steps 2 and 3
without ever requiring a database connection.

I know it's not the driver's main line of business, but since it is able
to do these things anyway (in PreparedStatement.toString), and they are
useful but non-trivial to do properly, why not expose the functionality?

I know very little about java and JDBC, so maybe this doesn't make sense.

BTW, thanks to Craig Servin and Mark Lewis for turning me on to
java.lang.reflect.Proxy.

Kevin Murphy


---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
    (send "unregister YourEmailAddressHere" to [hidden email])
Reply | Threaded
Open this post in threaded view
|

Re: Wish list

Oliver Jowett
Kevin Murphy wrote:

> it would be nice if the JDBC driver could somehow expose the
> functionality to do the quoting and escaping required in steps 2 and 3
> without ever requiring a database connection.
>
> I know it's not the driver's main line of business, but since it is able
> to do these things anyway (in PreparedStatement.toString), and they are
> useful but non-trivial to do properly, why not expose the functionality?

Uh, PreparedStatement.toString() *doesn't* necessarily produce correctly
quoted queries; the PostgreSQL driver implementation produces a query
string by blindly substituting parameter values with no escaping. It's
more of a debugging tool than anything else. At the protocol level, the
driver isn't escaping strings anyway because they're being passed
separately to the query in a Bind message rather than embedded in the
query string itself.

Also, the plans for post-8.1 string escaping mean that you will need to
know what version of the server you are talking to (or something
equivalent via a read-only GUC) to know which type of escaping is
correct.. it's hard to see how that works without a database connection.

-O

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
    (send "unregister YourEmailAddressHere" to [hidden email])