From 03194a68fe4d02d99fda4db7d07c0767a5885569 Mon Sep 17 00:00:00 2001 From: Sean Corfield Date: Thu, 29 Jul 2021 22:56:26 -0700 Subject: [PATCH] remove superfluous prev/next page links cljdoc adds these automatically now. --- doc/all-the-options.md | 2 -- doc/datafy-nav-and-schema.md | 2 -- doc/friendly-sql-functions.md | 2 -- doc/getting-started.md | 2 -- doc/migration-from-clojure-java-jdbc.md | 2 -- doc/prepared-statements.md | 2 -- doc/result-set-builders.md | 2 -- doc/tips-and-tricks.md | 2 -- doc/transactions.md | 2 -- 9 files changed, 18 deletions(-) diff --git a/doc/all-the-options.md b/doc/all-the-options.md index 5fc86ae..22a4409 100644 --- a/doc/all-the-options.md +++ b/doc/all-the-options.md @@ -107,5 +107,3 @@ The `transact` function and `with-transaction` macro accept the following option The `next.jdbc.plan/select!` function accepts the following specific option: * `:into` -- a data structure into which the selected result from a `plan` operation are poured; by default this is `[]`; could be any value that is acceptable as the first argument to `into`, subject to `into` accepting the sequence of values produced by the `plan` reduction. - -[<: Transactions](/doc/transactions.md) | [`datafy`, `nav`, and `:schema` :>](/doc/datafy-nav-and-schema.md) diff --git a/doc/datafy-nav-and-schema.md b/doc/datafy-nav-and-schema.md index bfe2173..57ee95f 100644 --- a/doc/datafy-nav-and-schema.md +++ b/doc/datafy-nav-and-schema.md @@ -79,5 +79,3 @@ If you require `next.jdbc.datafy`, the `Datafiable` protocol is extended to seve See the Java documentation for these JDBC types for further details on what all the properties from each of these classes mean and which are `int`, `String`, or some other JDBC object type. In addition, requiring this namespace will affect how `next.jdbc.result-set/metadata` behaves inside the reducing function applied to the result of `plan`. Without this namespace loaded, that function will return a raw `ResultSetMetaData` object (which must not leak outside the reducing function). With this namespace loaded, that function will, instead, return a Clojure data structure describing the columns in the result set. - -[<: All The Options](/doc/all-the-options.md) | [Migration from `clojure.java.jdbc` :>](/doc/migration-from-clojure-java-jdbc.md) diff --git a/doc/friendly-sql-functions.md b/doc/friendly-sql-functions.md index 40352dd..65a6ef7 100644 --- a/doc/friendly-sql-functions.md +++ b/doc/friendly-sql-functions.md @@ -262,5 +262,3 @@ By default, for compatibility with their default adapter (`clojure.java.jdbc`), (character-by-id ds {:id 1}) ;;=> #:CHARACTERS{:ID 1, :NAME "Westley", :SPECIALTY "love", :CREATED_AT #inst "2019-09-27T18:52:54.413000000-00:00"} ``` - -[<: Getting Started](/doc/getting-started.md) | [Tips & Tricks :>](/doc/tips-and-tricks.md) diff --git a/doc/getting-started.md b/doc/getting-started.md index e9549ce..ba985a5 100644 --- a/doc/getting-started.md +++ b/doc/getting-started.md @@ -673,5 +673,3 @@ A convenience function also exists to revert that instrumentation: ```clojure (specs/unstrument) ; undoes the instrumentation of all next.jdbc API functions ``` - -[Friendly SQL Functions :>](/doc/friendly-sql-functions.md) diff --git a/doc/migration-from-clojure-java-jdbc.md b/doc/migration-from-clojure-java-jdbc.md index 6847ed6..2b45c78 100644 --- a/doc/migration-from-clojure-java-jdbc.md +++ b/doc/migration-from-clojure-java-jdbc.md @@ -123,5 +123,3 @@ These are mostly drawn from [Issue #5](https://github.com/seancorfield/next-jdbc * `with-transaction` can take a `:rollback-only` option, but there is no built-in way to change a transaction to rollback _dynamically_; either throw an exception (all transactions roll back on an exception) or call `.rollback` directly on the `java.sql.Connection` object (see [Manual Rollback Inside a Transactions](/doc/transactions.md#manual-rollback-inside-a-transaction) and the following section about save points), * `clojure.java.jdbc` implicitly allowed transactions to nest and just silently ignored the inner, nested transactions (so you only really had the top-level, outermost transaction); `next.jdbc` by default assumes you know what you are doing and so an inner (nested) transaction will commit or rollback the work done so far in outer transaction (and then when that outer transaction ends, the remaining work is rolled back or committed); `next.jdbc.transaction/*nested-tx*` is a dynamic var that can be bound to `:ignore` to get the same behavior as `clojure.java.jdbc`. * The extension points for setting parameters and reading columns are now `SettableParameter` and `ReadableColumn` protocols. - -[<: `datafy`, `nav`, and `:schema`](/doc/datafy-nav-and-schema.md) diff --git a/doc/prepared-statements.md b/doc/prepared-statements.md index 7f795b5..da86b56 100644 --- a/doc/prepared-statements.md +++ b/doc/prepared-statements.md @@ -142,5 +142,3 @@ There are several caveats around using batched parameters. Some JDBC drivers nee In addition, if the batch operation fails for a group of parameters, it is database-specific whether the remaining groups of parameters are used, i.e., whether the operation is performed for any further groups of parameters after the one that failed. The result of calling `execute-batch!` is a vector of integers. Each element of the vector is the number of rows affected by the operation for each group of parameters. `execute-batch!` may throw a `BatchUpdateException` and calling `.getUpdateCounts` (or `.getLargeUpdateCounts`) on the exception may return an array containing a mix of update counts and error values (a Java `int[]` or `long[]`). Some databases don't always return an update count but instead a value indicating the number of rows is not known (but sometimes you can still get the update counts). Finally, some database drivers don't do batched operations at all -- they accept `.executeBatch` but they run the operation as separate commands for the database rather than a single batched command. - -[<: Result Set Builders](/doc/result-set-builders.md) | [Transactions :>](/doc/transactions.md) diff --git a/doc/result-set-builders.md b/doc/result-set-builders.md index bfc72ef..d34936d 100644 --- a/doc/result-set-builders.md +++ b/doc/result-set-builders.md @@ -150,5 +150,3 @@ The default implementation of this protocol is for these two functions to return Remember that a protocol extension will apply to all code running in your application so with the above code **all** timestamp values coming from the database will be converted to `java.time.Instant` for all queries. If you want to control behavior across different calls, consider the adapters described above (`as-maps-adapter`, `as-arrays-adapter`, and `builder-adapter`, and think about using metadata to implement the `rs/ReadableColumn` protocol instead of extending it). Note that the converse, converting Clojure values to database-specific types is handled by the `SettableParameter` protocol, discussed in the next section ([Prepared Statements](/doc/prepared-statements.md#prepared-statement-parameters)). - -[<: Tips & Tricks](/doc/tips-and-tricks.md) | [Prepared Statements :>](/doc/prepared-statements.md) diff --git a/doc/tips-and-tricks.md b/doc/tips-and-tricks.md index 19550f6..2663a4e 100644 --- a/doc/tips-and-tricks.md +++ b/doc/tips-and-tricks.md @@ -459,5 +459,3 @@ If you are using `plan`, you'll most likely be accessing columns by just the lab [] (jdbc/plan ds ["select * from some_table"])) ``` - -[<: Friendly SQL Functions](/doc/friendly-sql-functions.md) | [Result Set Builders :>](/doc/result-set-builders.md) diff --git a/doc/transactions.md b/doc/transactions.md index 97f067a..1f085cd 100644 --- a/doc/transactions.md +++ b/doc/transactions.md @@ -94,5 +94,3 @@ transactions in the code under test. * `next.jdbc.transaction/*nested-tx*` is initially set to `:allow` which allows nested calls but makes them overlap (as described above), * `(binding [next.jdbc.transaction/*nested-tx* :ignore] ...)` provides the same behavior as `clojure.java.jdbc` where nested calls are essentially ignored and only the outermost transaction takes effect, * `(binding [next.jdbc.transaction/*nested-tx* :prohibit] ...)` will cause any attempt to start a nested transaction to throw an exception instead; this could be a useful way to detect the potentially buggy behavior described above (for either `:allow` or `:ignore`). - -[<: Prepared Statements](/doc/prepared-statements.md) | [All The Options :>](/doc/all-the-options.md)