It looks like your library targets the clojure.java.jdbc library, but your documentation and announcements say clojure.jdbc. These are two separate libraries, so this is bound to add to the confusion that already exists. You should change any reference from clojure.jdbc to clojure.java.jdbc.

clojure.java.jdbc
clojure.jdbc

Thanks for the library. I think it does meet a need for postgresql boilerplate.

It is actually just a string type

And best of all, I get a different error from the reporter of the bug in irc.

I get a NullPointerException because PgPreparedStatement.getMetaData() returns null. The utterly quality pgjdbc code this goes through is not enlightening. Anyway, it appears .getMetaData is returning null inside an insert! which is breaking everything.

The probable outcome of this will be fixes to clojure.java.jdbc :/

I have a column that's defined as timestamp with time zone default now() not null.
When I try to set its value using ZonedDateTime, I get the above exception.
It seems that .getParameterTypeName returns timestamp with time zone instead of timestamptz.

http://www.postgresql.org/docs/current/static/datatype-binary.html

bytea <-> Bytebuffer?

One of the things I'm not satisfied about with the current test suite is the fact that we only test with the one configuration - we proclaim that you can choose hstore as the default, and while we test roundtripping through hstore, we don't actually have the ability to test whether when it's set as the default, it actually does what it says on the tin.

Because of the protocolly nature of this, I'm not entirely sure how to go about this. My current estimate is that we'll need to spin up isolated JVMs in the way that boot does, for which there are a couple of libraries of which I'm aware. Any other ideas I'd be interested in hearing, but I'd definitely like better test coverage in the wake of a conversation I had on github yesterday where they were experiencing some odd bugs and their "fix" was to add a catch-all case that just passed the input through unmodified. There are clearly some holes in our abstraction, and I want to flush them out.

As I alluded to in my last ticket, I'm aware that there are some holes in our abstraction and I want to plug them. See the discussion on this commit:
enragedginger@6137596

Firstly, I'd like to gather a list of what is falling through. @enragedginger - is it possible you could log anything that goes through the default case on your app? it would be really handy to figure out what's going wrong - i'm not deploying anything busy enough to flush it out until early next year.

As detailed in PR #4, I've added limited hstore support. There is a question of what we should do with hstore because it is a bit inconsistently treated compared to json. cheshire unpicks keywords and such when they are keys in maps. That's rather nice, should we try to emulate it? On the other hand, we can't even have actual numbers because jdbc boxes it into HashMap<String,String>

Travis sucks, but it sucks less than anything I don't have to host myself because I am lazy. My release manager is looking into how to fix travis builds that rely on postgres at the minute (because we need it for utrecht).

It would be nice to show off that our tests pass on a clean envrionment.

By this, I mean do we want to be able to accept as input something that we could convert to a given column, but not be able to generate as output?

Examples:

1. I can (as of pull requests) pass in a byte-array for a bytea and get one back out when it is queried. Do we want to be able to pass in a ByteBuffer, even though we will not generate one from a bytea field?
2. There are other date and time types in the standard library that we could use

Further question: do some of these indicate we should have some more options like :default-map? I am loathe to make it so easy to shoot yourself in the foot with DateTime-y things, but I can also see a valid use case for wanting e.g. java.util.Date even though it gives us a massive caveat

I really like clojure.spec. It would be pretty awesome if we could find a way to use it to provide clearer error messages if you misconfigure things, especially since with the one-way casts we're likely to add quite a few more keys.

We can't actually release it with spec in yet because it requires an alpha clojure 1.9, but when 1.9 is out, I think we should seriously consider requiring it, not least for the generative testing.

Thoughts? @ShaneKilkelly

The README and the project.clj say it's MIT-Licensed, but the LICENSE file is way too long for that. Looks vaguely like the Eclipse License from memory.

What is it supposed to be licensed under?

I haven't given too much thought to how this would work, but given that they usually contain security fixes, we should probably keep everything up to date and ensure the code still passes tests.

Ideal scenario is we find an RSS feed somewhere of pg jdbc releases and add a cronjob which pings it, updates it and submits a PR.

It would be nice to support pgjdbc-ng as well

The following problem description references the mpg code found here: "mpg/src/mpg/data.clj:56-64".

When querying a Postgres array of strings (varchar[]), the initial query works, but all subsequent queries throw the following error: 'org.postgresql.util.PSQLException: ERROR: column "" is of type character varying[] but expression is of type json. Hint: You will need to rewrite or cast the expression.'. A little investigation revealed that calling .getParameterTypeName on a JDBC ParameterMetaData object from a new PreparedStatement object returns "_varchar". This is an expected response for the mpg implementation of IPersistentVector#'set-parameter, which then uses "varchar" as the element type to create an array object that gets set on the PreparedStatement object. Once that array is set on the PreparedStatment, however, subsequent calls to get the parameter type name from the ParameterMetaData return "varchar[]". This is true for new instances of PreparedStatment objects using the same sql string and db connection. As a result, mpg's implementation of IPersistentVector#'set-parameter defaults to setting a JSON object instead of an array on the PreparedStatement. Hence, the Postgres error mentioned above. Since PreparedStatement objects seem to be cached (for the life of the database connection?) and reused with different query params, some changed state in the PreparedStatement object affects all future queries of that sql statement until the db connection is reset. Updating the sql statement to specify data type (i.e., <field-name>::varchar[]) doesn't seem to have an effect.

You can reproduce the issue with the following steps:

1. with postgres running, create a new database.
   createdb repro_bug

2. at a terminal window type:
   psql repro_bug -c 'create table foo (bar character varying(255)[])'

3. then evaluate the clojure code in the following gist: https://gist.github.com/cwyckoff/faa1cad80b64b726a4900f6fd30c841d

At the minute, I'd say the README is doing a better job. It might be nice to include a few fully working basic examples in an 'examples' directory, but I don't think we can add much more value by having just markdown, given the "gets out of your way" nature of the library.

I think the best value from this module is given in conjunction with utrecht and this might make a nice base for samples.

Thoughts?