Can I get commit access (seancorfield) to so I can work on java.jdbc?
I've been working on my own fork so far because I had no commit access
to the clojure/java.jdbc repo. I talked with Steve (Gilardi) off-list
and he doesn't seem to mind which one of us is the official
maintainer: he said "I'd like to be involved, but would be happy to
pass being the maintainer on to you or someone else if I continue to
be a frustrating bottleneck."
Also, how do I get a build job set up on Hudson for java.jdbc?
"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)
Added. Lots of people care about this one, so please keep us in the loop here on the dev list.
Aaron or Stuart can do the Hudson setup.
Thanx. My fork is all merged back to clojure/java.jdbc with the commit
history intact (thanx to ebneter on SO - merging across repos and
retaining history was new territory to me!).
> Lots of people care about this one, so please keep us in the loop here on the dev list.
So far the only stuff I've done is:
* setup pom.xml for maven
* remove dependencies on old c.c.* stuff
* replaced indexed with map-indexed per your advice (thanx Stu!)
* updated file header comments to match new namespaces and add migrating date
* mark *db* as ^:dynamic to satisfy latest 1.3.0 snapshot
And the only potentially controversial one (which is a
work-in-progress right now):
* have the PreparedStatement return generated keys so insert
operations return those keys
I need to clean that up so a) it only tries to return generated keys
for inserts (possibly only single inserts) and b) it returns just the
generated key value (not a data structure containing it). I'll need to
spend a while testing it against different databases to be sure I've
got that right.
I plan to move all the print-related stuff out of internal.clj into a
separate namespace, just for maintainability. And I'd love to get as
much input as possible on what folks want / need in java.jdbc!
The other big thing that needs doing - and here I need input from the
group - is that the 'tests' are currently just example code showing
how to use the library and they depend on Apache Derby. What are best
practices for library tests and what do folks suggest I do for
database access / support here so that the tests can be self-contained
yet relatively exhaustive?
Also, given that the current test file is really examples, should that
move to the README.md as documentation instead?
> Aaron or Stuart can do the Hudson setup.
That's awesome. I have added you ("cosmin") to the contrib group on github, so you should have commit access to java.data. Organize the project to match the naming and common maven conventions for new contrib (take a look at e.g. tools.logging for an example). Let us know if you need any help with this.