clj-record and log4jdbc

18 views
Skip to first unread message

Stuart Campbell

unread,
Sep 12, 2010, 4:40:50 AM9/12/10
to clj-record-dev
Hi,

I'm trying to configure automatic SQL logging via log4jdbc (http://
code.google.com/p/log4jdbc/), and have run into a bit of a problem
interacting with clj-record.

log4jdbc is configured by loading a proxy driver that intercepts and
logs statements before forwarding them to the real database driver.
The configuration also involves modifying the subprotocol of the JDBC
URL to e.g. "log4jdbc:derby".

This modification of the subprotocol causes clj-record.util/id-query-
for to throw an exception, since it expects a value of either "derby",
"postgresql", "mysql" or "h2". (Incidentally, doesn't this imply that
other databases won't work with clj-record?)

Anyway, just wondering if anybody had any suggestions on how to get
around this, or if there's a more suitable SQL-logging solution
available.

Thanks,
Stuart

John D. Hume

unread,
Sep 12, 2010, 8:47:34 AM9/12/10
to clj-rec...@googlegroups.com

I think any fix would require changing the code. Instead of an exact match it could do a regexp match, I guess. Can anyone suggest a cleaner solution?

-- sent all mobile-like

Mark Nutter

unread,
Sep 12, 2010, 9:02:45 AM9/12/10
to clj-rec...@googlegroups.com
How about if there were a :proxy-url option in the configuration? That
way you could easily turn the logging on or off, and the core code
could use the proxy url for the initial configuration, and then resume
the regular db stuff for the rest of it.

Mark

John D. Hume

unread,
Sep 12, 2010, 9:45:43 AM9/12/10
to clj-rec...@googlegroups.com

I forgot that id-query-for is a multimethod.

I believe (but it's been a while, and I can't try it right now) that without modifying clj-record you can call defmethod to add your own implementation for your subprotocol (which can just call id-query-for with a dummy db-spec that has the supported subprotocol value).

-- sent all mobile-like

On Sep 12, 2010 8:47 AM, "John D. Hume" <duelin....@gmail.com> wrote:

I think any fix would require changing the code. Instead of an exact match it could do a regexp match, I guess. Can anyone suggest a cleaner solution?

-- sent all mobile-like



On Sep 12, 2010 7:28 AM, "Stuart Campbell" <stuart.will...@gmail.com> wrote:
> Hi,
>

> I...

Stuart Campbell

unread,
Sep 12, 2010, 8:30:56 PM9/12/10
to clj-record-dev
On Sep 12, 11:45 pm, "John D. Hume" <duelin.mark...@gmail.com> wrote:
> I believe (but it's been a while, and I can't try it right now) that without
> modifying clj-record you can call defmethod to add your own implementation
> for your subprotocol (which can just call id-query-for with a dummy db-spec
> that has the supported subprotocol value).

That will probably work in the interim - I'll give it a shot.

> On Sep 12, 2010 8:47 AM, "John D. Hume" <duelin.mark...@gmail.com> wrote:
>
> I think any fix would require changing the code. Instead of an exact match
> it could do a regexp match, I guess. Can anyone suggest a cleaner solution?

It occurs to me that since id-query-for looks specifically for
the :subprotocol keyword, it won't work for the other kinds of db-
specs supported by clojure.contrib.sql (:datasource etc.).

Perhaps a more robust method would involve inspecting the
DatabaseMetaData[1] for a given Connection?

Thanks,
Stuart

[1] http://download.oracle.com/javase/1.5.0/docs/api/java/sql/DatabaseMetaData.html

Stuart Campbell

unread,
Sep 13, 2010, 9:16:10 PM9/13/10
to clj-record-dev
> On Sep 12, 2010 8:47 AM, "John D. Hume" <duelin.mark...@gmail.com> wrote:
>
> I think any fix would require changing the code. Instead of an exact match
> it could do a regexp match, I guess. Can anyone suggest a cleaner solution?

Maybe something along these lines:
http://github.com/harto/clj-record/commit/396e8cbc981f5f3d87bf71ef01931cd7f6979718
(not really tested)

I don't know how consistent the product naming convention is across
database drivers. Also, this change would break any "custom" id-query-
for methods.

Cheers,
Stuart
Reply all
Reply to author
Forward
0 new messages