Rename doc files (to match URL versions); fix all doc links

It feels like it ought to be easier to link between docs and have them 
work on both GitHub and cljdoc!
This commit is contained in:
Sean Corfield 2019-04-21 14:15:07 -07:00
parent 37c570f44c
commit 8c51fc20e6
9 changed files with 20 additions and 18 deletions

View file

@ -7,8 +7,8 @@ The next generation of `clojure.java.jdbc`: a new low-level Clojure wrapper for
[![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)](https://cljdoc.org/d/seancorfield/next.jdbc/CURRENT) [![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)](https://cljdoc.org/d/seancorfield/next.jdbc/CURRENT)
* [Getting Started](https://github.com/seancorfield/next-jdbc/blob/master/doc/getting_started.md) * [Getting Started](https://cljdoc.org/d/seancorfield/next.jdbc/CURRENT/doc/getting-started)
* [Migrating from `clojure.java.jdbc`](https://github.com/seancorfield/next-jdbc/blob/master/doc/differences.md) * [Migrating from `clojure.java.jdbc`](https://cljdoc.org/d/seancorfield/next.jdbc/CURRENT/doc/differences)
* 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). * 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).
## Motivation ## Motivation

View file

@ -1,8 +1,8 @@
{:cljdoc.doc/tree [["Readme" {:file "README.md"}] {:cljdoc.doc/tree [["Readme" {:file "README.md"}]
["Getting Started" {:file "doc/getting_started.md"} ["Getting Started" {:file "doc/getting-started.md"}
["Friendly SQL Functions" {:file "doc/friendly_sql_fns.md"}] ["Friendly SQL Functions" {:file "doc/friendly-sql-fns.md"}]
["Result Set Builders" {:file "doc/rs_builders.md"}] ["Result Set Builders" {:file "doc/rs-builders.md"}]
["Prepared Statements" {:file "doc/prepared_stmt.md"}] ["Prepared Statements" {:file "doc/prepared-stmt.md"}]
["Transactions" {:file "doc/transactions.md"}]] ["Transactions" {:file "doc/transactions.md"}]]
["All The Options" {:file "doc/options.md"}] ["All The Options" {:file "doc/options.md"}]
["Migration from clojure.java.jdbc" {:file "doc/differences.md"}]]} ["Migration from clojure.java.jdbc" {:file "doc/differences.md"}]]}

View file

@ -55,3 +55,5 @@ These are mostly drawn from Issue #5 although most of the bullets in that issue
* `with-db-connection` has been replaced by just `with-open` containing a call to `get-connection`, * `with-db-connection` has been replaced by just `with-open` containing a call to `get-connection`,
* `with-transaction` can take a `:rollback-only` option, but there is no way to change a transaction to rollback _dynamically_; throw an exception instead (all transactions roll back on an exception) * `with-transaction` can take a `:rollback-only` option, but there is no way to change a transaction to rollback _dynamically_; throw an exception instead (all transactions roll back on an exception)
* The extension points for setting parameters and reading columns are now `SettableParameter` and `ReadableColumn` protocols. * The extension points for setting parameters and reading columns are now `SettableParameter` and `ReadableColumn` protocols.
[<: All The Options](https://cljdoc.org/d/seancorfield/next.jdbc/CURRENT/doc/options)

View file

@ -1,6 +1,6 @@
# Friendly SQL Functions # Friendly SQL Functions
In [[Getting Started|getting_started]], we used `execute!` and `execute-one!` for all our SQL operations, except when we were reducing a result set. These functions (and `reducible!`) all expect a "connectable" and a vector containing a SQL string followed by any parameter values required. In [Getting Started](https://cljdoc.org/d/seancorfield/next.jdbc/CURRENT/doc/getting-started), we used `execute!` and `execute-one!` for all our SQL operations, except when we were reducing a result set. These functions (and `reducible!`) all expect a "connectable" and a vector containing a SQL string followed by any parameter values required.
A "connectable" can be a `javax.sql.DataSource`, a `java.sql.Connection`, or something that can produce a datasource (when `get-datasource` is called on it). It can also be a `java.sql.PreparedStatement` but we'll cover that a bit later... A "connectable" can be a `javax.sql.DataSource`, a `java.sql.Connection`, or something that can produce a datasource (when `get-datasource` is called on it). It can also be a `java.sql.PreparedStatement` but we'll cover that a bit later...
@ -152,4 +152,4 @@ These quoting functions can be provided to any of the friendly SQL functions abo
Note that the entity naming function is passed a string, the result of calling `name` on the keyword passed in. Also note that the default quoting functions do not handle schema-qualified names, such as `dbo.table_name` -- `sql-server` would produce `[dbo.table_name]` from that. Use the `schema` function to wrap the quoting function if you need that behavior, e.g,. `{:table-fn (schema sql-server)}` which would produce `[dbo].[table_name]`. Note that the entity naming function is passed a string, the result of calling `name` on the keyword passed in. Also note that the default quoting functions do not handle schema-qualified names, such as `dbo.table_name` -- `sql-server` would produce `[dbo.table_name]` from that. Use the `schema` function to wrap the quoting function if you need that behavior, e.g,. `{:table-fn (schema sql-server)}` which would produce `[dbo].[table_name]`.
[[Prev: Getting Started|getting_started]] [[Next: Row and Result Set Builders|rs_builders]] [<: Getting Started](https://cljdoc.org/d/seancorfield/next.jdbc/CURRENT/doc/getting-started) | [Row and Result Set Builders :>](https://cljdoc.org/d/seancorfield/next.jdbc/CURRENT/doc/getting-started/rs-builders)

View file

@ -61,7 +61,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`). 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]]. > 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).
We used `execute!` to create the `address` table, to insert a new row into it, and to query it. In all three cases, `execute!` returns a vector of hash maps with namespace-qualified keys, representing the result set from the operation, if available. When no result set is produced, `next.jdbc` returns a "result set" containing the "update count" from the operation (which is usually the number of rows affected). By default, H2 uses uppercase names and `next.jdbc` returns these as-is. We used `execute!` to create the `address` table, to insert a new row into it, and to query it. In all three cases, `execute!` returns a vector of hash maps with namespace-qualified keys, representing the result set from the operation, if available. When no result set is produced, `next.jdbc` returns a "result set" containing the "update count" from the operation (which is usually the number of rows affected). By default, H2 uses uppercase names and `next.jdbc` returns these as-is.
@ -136,4 +136,4 @@ If `with-transaction` is given a datasource, it will create and close the connec
(jdbc/execute! con ...)) ; committed (jdbc/execute! con ...)) ; committed
``` ```
[[Next: Friendly SQL Functions|friendly_sql_fns]] [Friendly SQL Functions :>](https://cljdoc.org/d/seancorfield/next.jdbc/CURRENT/doc/getting-started/friendly-sql-functions)

View file

@ -60,4 +60,4 @@ The `transact` function and `with-transaction` macro accept the following option
* `:read-only` -- a `Boolean` that indicates whether the transaction should be read-only or not (the default), * `:read-only` -- a `Boolean` that indicates whether the transaction should be read-only or not (the default),
* `:rollback-only` -- a `Boolean` that indicates whether the transaction should commit on success (the default) or rollback. * `:rollback-only` -- a `Boolean` that indicates whether the transaction should commit on success (the default) or rollback.
[[Prev: Transactions|transactions]] [[Next: Migration from `clojure.java.jdbc`|differences]] [<: Transaction](https://cljdoc.org/d/seancorfield/next.jdbc/CURRENT/doc/getting-started/transactions) | [Migration from `clojure.java.jdbc` :>](https://cljdoc.org/d/seancorfield/next.jdbc/CURRENT/doc/differences)

View file

@ -30,4 +30,4 @@ This can be extended to any Clojure data type, to provide a customized way to ad
If you need more specialized parameter handling than the protocol can provide, then you can create prepared statements explicitly, instead of letting `next.jdbc` do it for you, and then calling your own variant of `set-parameters` to install those parameters. If you need more specialized parameter handling than the protocol can provide, then you can create prepared statements explicitly, instead of letting `next.jdbc` do it for you, and then calling your own variant of `set-parameters` to install those parameters.
[[Prev: Row and Result Set Builders|rs_builders]] [[Next: Transactions|transactions]] [<: Row and Result Set Builders](https://cljdoc.org/d/seancorfield/next.jdbc/CURRENT/doc/getting-started/rs-builders) | [Transactions :>](https://cljdoc.org/d/seancorfield/next.jdbc/CURRENT/doc/getting-started/transactions)

View file

@ -1,6 +1,6 @@
# RowBuilder and ResultSetBuilder # RowBuilder and ResultSetBuilder
In [[Getting Started|getting_started]], it was noted that, by default, `execute!` and `execute-one!` return result sets as (vectors of) hash maps with namespace-qualified keys as-is. If your database naturally produces uppercase column names from the JDBC driver, that's what you'll get. If it produces mixed-case names, that's what you'll get. In [Getting Started](https://cljdoc.org/d/seancorfield/next.jdbc/CURRENT/doc/getting-started), it was noted that, by default, `execute!` and `execute-one!` return result sets as (vectors of) hash maps with namespace-qualified keys as-is. If your database naturally produces uppercase column names from the JDBC driver, that's what you'll get. If it produces mixed-case names, that's what you'll get.
The default builder for rows and result sets creates qualified keywords that match whatever case the JDBC driver produces. That builder is `next.jdbc.result-set/as-maps` but there are several options available: The default builder for rows and result sets creates qualified keywords that match whatever case the JDBC driver produces. That builder is `next.jdbc.result-set/as-maps` but there are several options available:
@ -48,6 +48,6 @@ The default implementation of this protocol is for these two functions to return
Common extensions here could include converting `java.sql.Timestamp` to `java.time.Instant` for example but `next.jdbc` makes no assumptions beyond `nil` and `Boolean`. Common extensions here could include converting `java.sql.Timestamp` to `java.time.Instant` for example but `next.jdbc` makes no assumptions beyond `nil` and `Boolean`.
Note that the converse, converting Clojure values to database-specific types is handled by the `SettableParameters`, discussed in the section on [[prepared statements|prepared_stmt#prepared-statement-parameters]] Note that the converse, converting Clojure values to database-specific types is handled by the `SettableParameters`, discussed in the next section (Prepared Statements).
[[Prev: Friendly SQL Functions|friendly_sql_fns]] [[Next: Prepared Statements|prepared_stmt]] [<: Friendly SQL Functions](https://cljdoc.org/d/seancorfield/next.jdbc/CURRENT/doc/getting-started/friendly-sql-functions) | [Prepared Statements :>](https://cljdoc.org/d/seancorfield/next.jdbc/CURRENT/doc/getting-started/prepared-stmt)

View file

@ -1,6 +1,6 @@
# Transactions # Transactions
The `transact` function and `with-transaction` macro were briefly mentioned in the [[Getting Started|getting_started]] section but we'll go into more detail here. The `transact` function and `with-transaction` macro were briefly mentioned in the [Getting Started](https://cljdoc.org/d/seancorfield/next.jdbc/CURRENT/doc/getting-started) section but we'll go into more detail here.
Although `(transact connectable thunk)` is available, it is expected that you will mostly use `(with-transaction [tx connectable] body...)` when you want to execute multiple SQL operations in the context of a single transaction so that is what this section focuses on. Although `(transact connectable thunk)` is available, it is expected that you will mostly use `(with-transaction [tx connectable] body...)` when you want to execute multiple SQL operations in the context of a single transaction so that is what this section focuses on.
@ -18,10 +18,10 @@ It is possible to tell `next.jdbc` to create connections that do not automatical
You can also provide an options map as the third element of the binding vector (or the third argument to the `transact` function). The following options are supported: You can also provide an options map as the third element of the binding vector (or the third argument to the `transact` function). The following options are supported:
* `:isolation` -- the isolation level for this transaction (see [[All The Options|options]] for specifics), * `:isolation` -- the isolation level for this transaction (see [All The Options](https://cljdoc.org/d/seancorfield/next.jdbc/CURRENT/doc/options) for specifics),
* `:read-only` -- set the transaction into read-only mode (if `true`), * `:read-only` -- set the transaction into read-only mode (if `true`),
* `:rollback-only` -- set the transaction to always rollback, even on success (if `true`). * `:rollback-only` -- set the transaction to always rollback, even on success (if `true`).
The latter can be particularly useful in tests, to run a series of SQL operations during a test and then roll them all back at the end. The latter can be particularly useful in tests, to run a series of SQL operations during a test and then roll them all back at the end.
[[Prev: Prepared Statements|prepared_stmt]] [[Next: All The Options|options]] [<: Prepared Statements](https://cljdoc.org/d/seancorfield/next.jdbc/CURRENT/doc/getting-started/prepared-stmt) | [All The Options :>](https://cljdoc.org/d/seancorfield/next.jdbc/CURRENT/doc/options)