diff --git a/CHANGELOG.md b/CHANGELOG.md index 583ee7e..09d8088 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -4,7 +4,8 @@ Only accretive/fixative changes will be made from now on. ## Stable Builds -* 1.1.next in progress +* 1.1.643 -- 2021-03-06 + * Change coordinates to `com.github.seancorfield/next.jdbc` (although new versions will continue to be deployed to `seancorfield/next.jdbc` for a while -- see the [Clojars Verified Group Names policy](https://github.com/clojars/clojars-web/wiki/Verified-Group-Names)). * Documented `next.jdbc.transaction/*nested-tx*` more thoroughly since that difference from `clojure.java.jdbc` has come up in conversation a few times recently. * Fix #158 by documenting (and testing) `:allowMultiQueries true` as an option for MySQL/MariaDB to allow multiple statements to be executed and multiple result sets to be returned. * Fix #157 by copying `next.jdbc.prepare/execute-batch!` to `next.jdbc/execute-batch!` (to avoid a circular dependency that previously relied on requiring `next.jdbc.result-set` at runtime -- which was problematic for GraalVM-based native compilation); **`next.jdbc.prepare/execute-batch!` is deprecated:** it will continue to exist and work, but is no longer documented. In addition, `next.jdbc.prepare/execute-batch!` now relies on a private `volatile!` in order to reference `next.jdbc.result-set/datafiable-result-set` so that it is GraalVM-friendly. Note: code that requires `next.jdbc.prepare` and uses `execute-batch!` without also requiring something that causes `next.jdbc.result-set` to be loaded will no longer return generated keys from `execute-batch!` but that's an almost impossible path since nearly all code that uses `execute-batch!` will have called `next.jdbc/prepare` to get the `PreparedStatement` in the first place. diff --git a/README.md b/README.md index 233118b..45f1931 100644 --- a/README.md +++ b/README.md @@ -8,15 +8,15 @@ The next generation of `clojure.java.jdbc`: a new low-level Clojure wrapper for The latest versions on Clojars and on cljdoc: -[![Clojars Project](https://clojars.org/seancorfield/next.jdbc/latest-version.svg)](https://clojars.org/seancorfield/next.jdbc) [![cljdoc badge](https://cljdoc.org/badge/seancorfield/next.jdbc?1.1.613)](https://cljdoc.org/d/seancorfield/next.jdbc/CURRENT) +[![Clojars Project](https://clojars.org/com.github.seancorfield/next.jdbc/latest-version.svg)](https://clojars.org/com.github.seancorfield/next.jdbc) [![cljdoc badge](https://cljdoc.org/badge/com.github.seancorfield/next.jdbc?1.1.643)](https://cljdoc.org/d/com.github.seancorfield/next.jdbc/CURRENT) -The documentation on [cljdoc.org](https://cljdoc.org/d/seancorfield/next.jdbc/CURRENT) is for the current version of `next.jdbc`: +The documentation on [cljdoc.org](https://cljdoc.org/d/com.github.seancorfield/next.jdbc/CURRENT) is for the current version of `next.jdbc`: -* [Getting Started](https://cljdoc.org/d/seancorfield/next.jdbc/CURRENT/doc/getting-started) -* [Migrating from `clojure.java.jdbc`](https://cljdoc.org/d/seancorfield/next.jdbc/CURRENT/doc/migration-from-clojure-java-jdbc) +* [Getting Started](https://cljdoc.org/d/com.github.seancorfield/next.jdbc/CURRENT/doc/getting-started) +* [Migrating from `clojure.java.jdbc`](https://cljdoc.org/d/com.github.seancorfield/next.jdbc/CURRENT/doc/migration-from-clojure-java-jdbc) * Feedback via [issues](https://github.com/seancorfield/next-jdbc/issues) or in the [`#sql` channel on the Clojurians Slack](https://clojurians.slack.com/messages/C1Q164V29/details/) or the [`#sql` stream on the Clojurians Zulip](https://clojurians.zulipchat.com/#narrow/stream/152063-sql). -The documentation on GitHub is for **develop** since the 1.1.613 release -- [see the CHANGELOG](https://github.com/seancorfield/next-jdbc/blob/develop/CHANGELOG.md) and then read the [corresponding updated documentation](https://github.com/seancorfield/next-jdbc/tree/develop/doc) on GitHub if you want. +The documentation on GitHub is for **develop** since the 1.1.643 release -- [see the CHANGELOG](https://github.com/seancorfield/next-jdbc/blob/develop/CHANGELOG.md) and then read the [corresponding updated documentation](https://github.com/seancorfield/next-jdbc/tree/develop/doc) on GitHub if you want. This project follows the version scheme MAJOR.MINOR.COMMITS where MAJOR and MINOR provide some relative indication of the size of the change, but do not follow semantic versioning. In general, all changes endeavor to be non-breaking (by moving to new names rather than by breaking existing names). COMMITS is an ever-increasing counter of commits since the beginning of this repository. @@ -34,7 +34,7 @@ I also wanted `datafy`/`nav` support baked right in (it was added to `clojure.ja As `next.jdbc` moved from alpha to beta, the last breaking change was made (renaming `reducible!` to `plan`) and the API should be considered stable. Only accretive and fixative changes will be made from now on. -After a month of alpha builds being available for testing, the first beta build was released on May 24th, 2019. A release candidate followed on June 4th and the "gold" (1.0.0) release was on June 12th. In addition to the small, core API in `next.jdbc`, there are "syntactic sugar" SQL functions (`insert!`, `query`, `update!`, and `delete!`) available in `next.jdbc.sql` that are similar to the main API in `clojure.java.jdbc`. See [Migrating from `clojure.java.jdbc`](https://cljdoc.org/d/seancorfield/next.jdbc/CURRENT/doc/migration-from-clojure-java-jdbc) for more detail about the differences. +After a month of alpha builds being available for testing, the first beta build was released on May 24th, 2019. A release candidate followed on June 4th and the "gold" (1.0.0) release was on June 12th. In addition to the small, core API in `next.jdbc`, there are "syntactic sugar" SQL functions (`insert!`, `query`, `update!`, and `delete!`) available in `next.jdbc.sql` that are similar to the main API in `clojure.java.jdbc`. See [Migrating from `clojure.java.jdbc`](https://cljdoc.org/d/com.github.seancorfield/next.jdbc/CURRENT/doc/migration-from-clojure-java-jdbc) for more detail about the differences. ## Usage diff --git a/deps.edn b/deps.edn index a042fa5..5cdab47 100644 --- a/deps.edn +++ b/deps.edn @@ -43,7 +43,7 @@ :main-opts ["-m" "cognitect.test-runner" "-d" "test"]} :jar - {:replace-deps {seancorfield/depstar {:mvn/version "2.0.171"}} + {:replace-deps {com.github.seancorfield/depstar {:mvn/version "2.0.193"}} :exec-fn hf.depstar/jar :exec-args {:jar "next-jdbc.jar" :sync-pom true}} :deploy diff --git a/doc/friendly-sql-functions.md b/doc/friendly-sql-functions.md index 7fd7a8b..8c99e46 100644 --- a/doc/friendly-sql-functions.md +++ b/doc/friendly-sql-functions.md @@ -60,7 +60,7 @@ database. Several databases have a limit of 1,000 parameter placeholders. Oracle does not support this form of multi-row insert, requiring a different syntax altogether. -You should look at [`next.jdbc/execute-batch!`](https://cljdoc.org/d/seancorfield/next.jdbc/CURRENT/api/next.jdbc#execute-batch!) for an alternative approach. +You should look at [`next.jdbc/execute-batch!`](https://cljdoc.org/d/com.github.seancorfield/next.jdbc/CURRENT/api/next.jdbc#execute-batch!) for an alternative approach. ## `query` @@ -202,7 +202,7 @@ If you have [camel-snake-kebab](https://clj-commons.org/camel-snake-kebab/) on y ## HugSQL Quick Start -Here's how to get up and running quickly with `next.jdbc` and HugSQL. For more detail, consult the [HugSQL documentation](https://www.hugsql.org/). Add the following dependencies to your project (in addition to `seancorfield/next.jdbc` and whichever JDBC drivers you need): +Here's how to get up and running quickly with `next.jdbc` and HugSQL. For more detail, consult the [HugSQL documentation](https://www.hugsql.org/). Add the following dependencies to your project (in addition to `com.github.seancorfield/next.jdbc` and whichever JDBC drivers you need): ```clojure com.layerware/hugsql-core {:mvn/version "0.5.1"} diff --git a/doc/getting-started.md b/doc/getting-started.md index 05fd3e0..ec00140 100644 --- a/doc/getting-started.md +++ b/doc/getting-started.md @@ -11,12 +11,12 @@ It is designed to work with Clojure 1.10 or later, supports `datafy`/`nav`, and You can add `next.jdbc` to your project with either: ```clojure -seancorfield/next.jdbc {:mvn/version "1.1.613"} +com.github.seancorfield/next.jdbc {:mvn/version "1.1.643"} ``` for `deps.edn` or: ```clojure -[seancorfield/next.jdbc "1.1.613"] +[com.github.seancorfield/next.jdbc "1.1.643"] ``` for `project.clj` or `build.boot`. @@ -31,7 +31,7 @@ For the examples in this documentation, we will use a local H2 database on disk, ```clojure ;; deps.edn {:deps {org.clojure/clojure {:mvn/version "1.10.2"} - seancorfield/next.jdbc {:mvn/version "1.1.613"} + com.github.seancorfield/next.jdbc {:mvn/version "1.1.643"} com.h2database/h2 {:mvn/version "1.4.199"}}} ``` @@ -68,7 +68,7 @@ user=> We described the database with just `:dbtype` and `:dbname` because it is created as a local file and needs no authentication. For most databases, you would need `:user` and `:password` for authentication, and if the database is running on a remote machine you would need `:host` and possibly `:port` (`next.jdbc` tries to guess the correct port based on the `:dbtype`). -> Note: You can see the full list of `:dbtype` values supported in [next.jdbc/get-datasource](https://cljdoc.org/d/seancorfield/next.jdbc/CURRENT/api/next.jdbc#get-datasource)'s docstring. If you need this programmatically, you can get it from the [next.jdbc.connection/dbtypes](https://cljdoc.org/d/seancorfield/next.jdbc/CURRENT/api/next.jdbc.connection#dbtypes) hash map. If those lists differ, the hash map is the definitive list (and I'll need to fix the docstring!). The docstring of that Var explains how to tell `next.jdbc` about additional databases. +> Note: You can see the full list of `:dbtype` values supported in [next.jdbc/get-datasource](https://cljdoc.org/d/com.github.seancorfield/next.jdbc/CURRENT/api/next.jdbc#get-datasource)'s docstring. If you need this programmatically, you can get it from the [next.jdbc.connection/dbtypes](https://cljdoc.org/d/com.github.seancorfield/next.jdbc/CURRENT/api/next.jdbc.connection#dbtypes) hash map. If those lists differ, the hash map is the definitive list (and I'll need to fix the docstring!). The docstring of that Var explains how to tell `next.jdbc` about additional databases. If you already have a JDBC URL (string), you can use that as-is instead of the db-spec hash map. If you have a JDBC URL and still need additional options passed into the JDBC driver, you can use a hash map with the `:jdbcUrl` key specifying the string and whatever additional options you need. @@ -513,7 +513,7 @@ If you are using [Component](https://github.com/stuartsierra/component), a conne By default, `next.jdbc` relies on the JDBC driver to handle all data type conversions when reading from a result set (to produce Clojure values from SQL values) or setting parameters (to produce SQL values from Clojure values). Sometimes that means that you will get back a database-specific Java object that would need to be manually converted to a Clojure data structure, or that certain database column types require you to manually construct the appropriate database-specific Java object to pass into a SQL operation. You can usually automate those conversions using either the [`ReadableColumn` protocol](/doc/result-set-builders.md#readablecolumn) (for converting database-specific types to Clojure values) or the [`SettableParameter` protocol](/doc/prepared-statements.md#prepared-statement-parameters) (for converting Clojure values to database-specific types). -In particular, PostgreSQL does not seem to perform a conversion from `java.util.Date` to a SQL data type automatically. You can `require` the [`next.jdbc.date-time` namespace](https://cljdoc.org/d/seancorfield/next.jdbc/CURRENT/api/next.jdbc.date-time) to enable that conversion. +In particular, PostgreSQL does not seem to perform a conversion from `java.util.Date` to a SQL data type automatically. You can `require` the [`next.jdbc.date-time` namespace](https://cljdoc.org/d/com.github.seancorfield/next.jdbc/CURRENT/api/next.jdbc.date-time) to enable that conversion. If you are working with Java Time, some JDBC drivers will automatically convert `java.time.Instant` (and `java.time.LocalDate` and `java.time.LocalDateTime`) to a SQL data type automatically, but others will not. Requiring `next.jdbc.date-time` will enable those automatic conversions for all databases. diff --git a/doc/prepared-statements.md b/doc/prepared-statements.md index 3dfe98b..8ba23ce 100644 --- a/doc/prepared-statements.md +++ b/doc/prepared-statements.md @@ -46,7 +46,7 @@ This can be extended to any Clojure data type, to provide a customized way to ad (.setTimestamp ps i (java.sql.Timestamp/valueOf v)))) ``` -> Note: those conversions can also be enabled by requiring the [`next.jdbc.date-time` namespace](https://cljdoc.org/d/seancorfield/next.jdbc/CURRENT/api/next.jdbc.date-time). +> Note: those conversions can also be enabled by requiring the [`next.jdbc.date-time` namespace](https://cljdoc.org/d/com.github.seancorfield/next.jdbc/CURRENT/api/next.jdbc.date-time). You can also extend this protocol via metadata so you can do it on a per-object basis if you need: diff --git a/doc/tips-and-tricks.md b/doc/tips-and-tricks.md index 010c7ff..420fdfe 100644 --- a/doc/tips-and-tricks.md +++ b/doc/tips-and-tricks.md @@ -196,7 +196,7 @@ create table example( ### Working with Date and Time By default, PostgreSQL's JDBC driver does not always perform conversions from `java.util.Date` to a SQL data type. -You can enable this by extending `SettableParameter` to the appropriate (Java) types, or by simply requiring [`next.jdbc.date-time`](https://cljdoc.org/d/seancorfield/next.jdbc/CURRENT/api/next.jdbc.date-time). +You can enable this by extending `SettableParameter` to the appropriate (Java) types, or by simply requiring [`next.jdbc.date-time`](https://cljdoc.org/d/com.github.seancorfield/next.jdbc/CURRENT/api/next.jdbc.date-time). In addition, if you want `java.time.Instant`, `java.time.LocalDate`, and `java.time.LocalDateTime` to be automatically converted to SQL data types, requiring `next.jdbc.date-time` will enable those as well (by extending `SettableParameter` for you). diff --git a/pom.xml b/pom.xml index 8a3cfc4..02dfaf0 100644 --- a/pom.xml +++ b/pom.xml @@ -1,9 +1,9 @@ 4.0.0 - seancorfield + com.github.seancorfield next.jdbc - 1.1.613 + 1.1.643 next.jdbc The next generation of clojure.java.jdbc: a new low-level Clojure wrapper for JDBC-based access to databases. https://github.com/seancorfield/next-jdbc @@ -22,13 +22,13 @@ https://github.com/seancorfield/next-jdbc scm:git:git://github.com/seancorfield/next-jdbc.git scm:git:ssh://git@github.com/seancorfield/next-jdbc.git - v1.1.613 + v1.1.643 org.clojure clojure - 1.10.1 + 1.10.2 org.clojure diff --git a/src/next/jdbc.clj b/src/next/jdbc.clj index 510c096..673a9a2 100644 --- a/src/next/jdbc.clj +++ b/src/next/jdbc.clj @@ -129,7 +129,7 @@ * `timesten:direct` -- `com.timesten.jdbc.TimesTenDriver` For more details about `:dbtype` and `:classname` values, see: - https://cljdoc.org/d/seancorfield/next.jdbc/CURRENT/api/next.jdbc.connection#dbtypes" + https://cljdoc.org/d/com.github.seancorfield/next.jdbc/CURRENT/api/next.jdbc.connection#dbtypes" ^javax.sql.DataSource [spec] (p/get-datasource spec)) @@ -291,7 +291,7 @@ get more information about which parts succeeded and which failed. For additional caveats and database-specific options you may need, see: - https://cljdoc.org/d/seancorfield/next.jdbc/CURRENT/doc/getting-started/prepared-statements#caveats + https://cljdoc.org/d/com.github.seancorfield/next.jdbc/CURRENT/doc/getting-started/prepared-statements#caveats Not all databases support batch execution." ([ps param-groups] diff --git a/src/next/jdbc/prepare.clj b/src/next/jdbc/prepare.clj index bd08766..2accdf5 100644 --- a/src/next/jdbc/prepare.clj +++ b/src/next/jdbc/prepare.clj @@ -10,11 +10,11 @@ Defines the `SettableParameter` protocol for converting Clojure values to database-specific values. - See also https://cljdoc.org/d/seancorfield/next.jdbc/CURRENT/api/next.jdbc.date-time + See also https://cljdoc.org/d/com.github.seancorfield/next.jdbc/CURRENT/api/next.jdbc.date-time for implementations of `SettableParameter` that provide automatic conversion of Java Time objects to SQL data types. - See also https://cljdoc.org/d/seancorfield/next.jdbc/CURRENT/api/next.jdbc.types + See also https://cljdoc.org/d/com.github.seancorfield/next.jdbc/CURRENT/api/next.jdbc.types for `as-xxx` functions that provide per-instance implementations of `SettableParameter` for each of the standard `java.sql.Types` values." (:require [clojure.java.data :as j] diff --git a/src/next/jdbc/result_set.clj b/src/next/jdbc/result_set.clj index 96a0b31..ade7722 100644 --- a/src/next/jdbc/result_set.clj +++ b/src/next/jdbc/result_set.clj @@ -14,7 +14,7 @@ Also provides the default implementations for `Executable` and the default `datafy`/`nav` behavior for rows from a result set. - See also https://cljdoc.org/d/seancorfield/next.jdbc/CURRENT/api/next.jdbc.date-time + See also https://cljdoc.org/d/com.github.seancorfield/next.jdbc/CURRENT/api/next.jdbc.date-time for implementations of `ReadableColumn` that provide automatic conversion of some SQL data types to Java Time objects." (:require [clojure.core.protocols :as core-p]