Coder Social home page Coder Social logo

honeysql's Introduction

Honey SQL Clojure CI Release Clojure CI Develop Clojure CI Pull Request

SQL as Clojure data structures. Build queries programmatically -- even at runtime -- without having to bash strings together.

Build

Clojars cljdoc Slack Join Slack

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.

Note: every commit to the develop branch runs CI (GitHub Actions) and successful runs push a MAJOR.MINOR.9999-SNAPSHOT build to Clojars so the very latest version of HoneySQL is always available either via that snapshot on Clojars or via a git dependency on the latest SHA.

HoneySQL 2.x requires Clojure 1.9 or later.

Compared to 1.x, HoneySQL 2.x provides a streamlined codebase and a simpler method for extending the DSL. It also supports SQL dialects out-of-the-box and will be extended to support vendor-specific language features over time (unlike 1.x).

Note: you can use 1.x and 2.x side-by-side as they use different group IDs and different namespaces. This allows for a piecemeal migration. See this summary of differences between 1.x and 2.x if you are migrating from 1.x!

Try HoneySQL Online!

John Shaffer has created this awesome HoneySQL web app, written in ClojureScript, so you can experiment with HoneySQL in a browser, including setting different options so you can generate pretty SQL with inline values (via :inline true) for copying and pasting directly into your SQL tool of choice!

Note on code samples

Sample code in this documentation is verified via lread/test-doc-blocks.

Some of these samples show pretty-printed SQL: HoneySQL 2.x supports :pretty true which inserts newlines between clauses in the generated SQL strings.

HoneySQL 1.x (legacy)

Clojars cljdoc badge

HoneySQL 1.x will continue to get critical security fixes but otherwise should be considered "legacy" at this point.

Usage

This section includes a number of usage examples but does not dive deep into the way the data structure acts as a DSL that can specify SQL statements (as hash maps) and SQL expressions and function calls (as vectors). It is recommended that you read the Getting Started section of the documentation before trying to use HoneySQL to build your own queries!

From Clojure:

(refer-clojure :exclude '[distinct filter for group-by into partition-by set update])
(require '[honey.sql :as sql]
         ;; CAUTION: this overwrites several clojure.core fns:
         ;;
         ;; distinct, filter, for, group-by, into, partition-by, set, and update
         ;;
         ;; you should generally only refer in the specific
         ;; helpers that you want to use!
         '[honey.sql.helpers :refer :all :as h]
         ;; so we can still get at clojure.core functions:
         '[clojure.core :as c])

From ClojureScript, we don't have :refer :all. If we want to use :refer, we have no choice but to be specific:

(refer-clojure :exclude '[filter for group-by into partition-by set update])
(require '[honey.sql :as sql]
         '[honey.sql.helpers :refer [select select-distinct from
                                     join left-join right-join
                                     where for group-by having union
                                     order-by limit offset values columns
                                     update insert-into set composite
                                     delete delete-from truncate] :as h]
         '[clojure.core :as c])

Everything is built on top of maps representing SQL queries:

(def sqlmap {:select [:a :b :c]
             :from   [:foo]
             :where  [:= :foo.a "baz"]})

Column names can be provided as keywords or symbols (but not strings -- HoneySQL treats strings as values that should be lifted out of the SQL as parameters).

format

format turns maps into next.jdbc-compatible (and clojure.java.jdbc-compatible), parameterized SQL:

(sql/format sqlmap)
=> ["SELECT a, b, c FROM foo WHERE foo.a = ?" "baz"]
;; sqlmap as symbols instead of keywords:
(-> '{select (a, b, c) from (foo) where (= foo.a "baz")}
    (sql/format))
=> ["SELECT a, b, c FROM foo WHERE foo.a = ?" "baz"]

HoneySQL is a relatively "pure" library, it does not manage your JDBC connection or run queries for you, it simply generates SQL strings. You can then pass them to a JDBC library, such as next.jdbc:

(jdbc/execute! conn (sql/format sqlmap))

Note: you'll need to add your preferred JDBC library as a dependency in your project -- HoneySQL deliberately does not make that choice for you.

If you want to format the query as a string with no parameters (e.g. to use the SQL statement in a SQL console), pass :inline true as an option to sql/format:

(sql/format sqlmap {:inline true})
=> ["SELECT a, b, c FROM foo WHERE foo.a = 'baz'"]

As seen above, the default parameterization uses positional parameters (?) with the order of values in the generated vector matching the order of those placeholders in the SQL. As of 2.4.962, you can specified :numbered true as an option to produce numbered parameters ($1, $2, etc):

(sql/format sqlmap {:numbered true})
=> ["SELECT a, b, c FROM foo WHERE foo.a = $1" "baz"]

Namespace-qualified keywords (and symbols) are generally treated as table-qualified columns: :foo/bar becomes foo.bar, except in contexts where that would be illegal (such as the list of columns in an INSERT statement). This approach is likely to be more compatible with code that uses libraries like next.jdbc and seql, as well as being more convenient in a world of namespace-qualified keywords, following the example of clojure.spec etc.

(def q-sqlmap {:select [:foo/a :foo/b :foo/c]
               :from   [:foo]
               :where  [:= :foo/a "baz"]})
(sql/format q-sqlmap)
=> ["SELECT foo.a, foo.b, foo.c FROM foo WHERE foo.a = ?" "baz"]
;; this also works with symbols instead of keywords:
(-> '{select (foo/a, foo/b, foo/c)
      from   (foo)
      where  (= foo/a "baz")}
    (sql/format))
=> ["SELECT foo.a, foo.b, foo.c FROM foo WHERE foo.a = ?" "baz"]

As of 2.6.1126, there is a helper macro you can use with quoted symbolic queries (that are purely literal, not programmatically constructed) to provide "escape hatches" for certain symbols that you want to be treated as locally bound symbols (and, hence, their values):

;; quoted symbolic query with local substitution:
(let [search-value "baz"]
  (sql/formatv [search-value]
   '{select (foo/a, foo/b, foo/c)
     from   (foo)
     where  (= foo/a search-value)}))
=> ["SELECT foo.a, foo.b, foo.c FROM foo WHERE foo.a = ?" "baz"]

Note: this is a Clojure-only feature and is not available in ClojureScript, and it is intended for literal, inline symbolic queries only, not for programmatically constructed queries (where you would be able to substitute the values directly, as you build the query).

Documentation for the entire data DSL can be found in the Clause Reference, the Operator Reference, and the Special Syntax reference.

Vanilla SQL clause helpers

For every single SQL clause supported by HoneySQL (as keywords or symbols in the data structure that is the DSL), there is also a corresponding function in the honey.sql.helpers namespace:

(-> (select :a :b :c)
    (from :foo)
    (where [:= :foo.a "baz"]))
=> {:select [:a :b :c] :from [:foo] :where [:= :foo.a "baz"]}

In general, (helper :foo expr) will produce {:helper [:foo expr]} (with a few exceptions -- see the docstring of the helper function for details).

Order doesn't matter (for independent clauses):

(= (-> (select :*) (from :foo))
   (-> (from :foo) (select :*)))
=> true

When using the vanilla helper functions, repeated clauses will be merged into existing clauses, in the natural evaluation order (where that makes sense):

(-> sqlmap (select :d))
=> {:from [:foo], :where [:= :foo.a "baz"], :select [:a :b :c :d]}

If you want to replace a clause, you can dissoc the existing clause first, since this is all data:

(-> sqlmap
    (dissoc :select)
    (select :*)
    (where [:> :b 10])
    sql/format)
=> ["SELECT * FROM foo WHERE (foo.a = ?) AND (b > ?)" "baz" 10]

Note: the helpers always produce keywords so you can rely on dissoc with the desired keyword to remove. If you are building the data DSL "manually" and using symbols instead of keywords, you'll need to dissoc the symbol form instead.

where will combine multiple clauses together using SQL's AND:

(-> (select :*)
    (from :foo)
    (where [:= :a 1] [:< :b 100])
    sql/format)
=> ["SELECT * FROM foo WHERE (a = ?) AND (b < ?)" 1 100]

Column and table names may be aliased by using a vector pair of the original name and the desired alias:

(-> (select :a [:b :bar] :c [:d :x])
    (from [:foo :quux])
    (where [:= :quux.a 1] [:< :bar 100])
    sql/format)
=> ["SELECT a, b AS bar, c, d AS x FROM foo AS quux WHERE (quux.a = ?) AND (bar < ?)" 1 100]

In particular, note that (select [:a :b]) means SELECT a AS b rather than SELECT a, b -- helpers like select are generally variadic and do not take a collection of column names.

The examples in this README use a mixture of data structures and the helper functions interchangably. For any example using the helpers, you could evaluate it (without the call to sql/format) to see what the equivalent data structure would be.

Documentation for all the helpers can be found in the honey.sql.helpers API reference.

Inserts

Inserts are supported in two patterns. In the first pattern, you must explicitly specify the columns to insert, then provide a collection of rows, each a collection of column values:

(-> (insert-into :properties)
    (columns :name :surname :age)
    (values
     [["Jon" "Smith" 34]
      ["Andrew" "Cooper" 12]
      ["Jane" "Daniels" 56]])
    (sql/format {:pretty true}))
=> ["
INSERT INTO properties (name, surname, age)
VALUES (?, ?, ?), (?, ?, ?), (?, ?, ?)
"
"Jon" "Smith" 34 "Andrew" "Cooper" 12 "Jane" "Daniels" 56]
;; or as pure data DSL:
(-> {:insert-into [:properties]
     :columns [:name :surname :age]
     :values [["Jon" "Smith" 34]
              ["Andrew" "Cooper" 12]
              ["Jane" "Daniels" 56]]}
    (sql/format {:pretty true}))
=> ["
INSERT INTO properties (name, surname, age)
VALUES (?, ?, ?), (?, ?, ?), (?, ?, ?)
"
"Jon" "Smith" 34 "Andrew" "Cooper" 12 "Jane" "Daniels" 56]

If the rows are of unequal lengths, they will be padded with NULL values to make them consistent.

Alternately, you can simply specify the values as maps:

(-> (insert-into :properties)
    (values [{:name "John" :surname "Smith" :age 34}
             {:name "Andrew" :surname "Cooper" :age 12}
             {:name "Jane" :surname "Daniels" :age 56}])
    (sql/format {:pretty true}))
=> ["
INSERT INTO properties (name, surname, age)
VALUES (?, ?, ?), (?, ?, ?), (?, ?, ?)
"
"John" "Smith" 34
"Andrew" "Cooper"  12
"Jane" "Daniels" 56]
;; or as pure data DSL:
(-> {:insert-into [:properties]
     :values [{:name "John", :surname "Smith", :age 34}
              {:name "Andrew", :surname "Cooper", :age 12}
              {:name "Jane", :surname "Daniels", :age 56}]}
    (sql/format {:pretty true}))
=> ["
INSERT INTO properties (name, surname, age)
VALUES (?, ?, ?), (?, ?, ?), (?, ?, ?)
"
"John" "Smith" 34
"Andrew" "Cooper"  12
"Jane" "Daniels" 56]

The set of columns used in the insert will be the union of all column names from all the hash maps: columns that are missing from any rows will have NULL as their value unless you specify those columns in the :values-default-columns option, which takes a set of column names that should get the value DEFAULT instead of NULL:

(-> (insert-into :properties)
    (values [{:name "John" :surname "Smith" :age 34}
             {:name "Andrew" :age 12}
             {:name "Jane" :surname "Daniels"}])
    (sql/format {:pretty true}))
=> ["
INSERT INTO properties (name, surname, age)
VALUES (?, ?, ?), (?, NULL, ?), (?, ?, NULL)
"
"John" "Smith" 34
"Andrew" 12
"Jane" "Daniels"]
(-> (insert-into :properties)
    (values [{:name "John" :surname "Smith" :age 34}
             {:name "Andrew" :age 12}
             {:name "Jane" :surname "Daniels"}])
    (sql/format {:pretty true :values-default-columns #{:age}}))
=> ["
INSERT INTO properties (name, surname, age)
VALUES (?, ?, ?), (?, NULL, ?), (?, ?, DEFAULT)
"
"John" "Smith" 34
"Andrew" 12
"Jane" "Daniels"]

Nested subqueries

The column values do not have to be literals, they can be nested queries:

(let [user-id 12345
      role-name "user"]
  (-> (insert-into :user_profile_to_role)
      (values [{:user_profile_id user-id
                :role_id         (-> (select :id)
                                     (from :role)
                                     (where [:= :name role-name]))}])
      (sql/format {:pretty true})))

=> ["
INSERT INTO user_profile_to_role (user_profile_id, role_id)
VALUES (?, (SELECT id FROM role WHERE name = ?))
"
12345
"user"]
;; or as pure data DSL:
(let [user-id 12345
      role-name "user"]
  (-> {:insert-into [:user_profile_to_role]
       :values [{:user_profile_id 12345,
                 :role_id {:select [:id],
                           :from [:role],
                           :where [:= :name "user"]}}]}
      (sql/format {:pretty true})))
=> ["
INSERT INTO user_profile_to_role (user_profile_id, role_id)
VALUES (?, (SELECT id FROM role WHERE name = ?))
"
12345
"user"]
(-> (select :*)
    (from :foo)
    (where [:in :foo.a (-> (select :a) (from :bar))])
    (sql/format))
=> ["SELECT * FROM foo WHERE foo.a IN (SELECT a FROM bar)"]
;; or as pure data DSL:
(-> {:select [:*],
     :from [:foo],
     :where [:in :foo.a {:select [:a], :from [:bar]}]}
    (sql/format))
=> ["SELECT * FROM foo WHERE foo.a IN (SELECT a FROM bar)"]

Because values can be nested queries -- and also because values can be function calls -- whenever you are working with values that are, themselves, structured data, you will need to tell HoneySQL not to interpret that structured data as part of the DSL. This especially affects using JSON values with HoneySQL (e.g., targeting PostgreSQL). There are two possible approaches:

  1. Use named parameters instead of having the values directly in the DSL structure (see :param under Miscellaneous below), or
  2. Use [:lift ..] wrapped around any structured values which tells HoneySQL not to interpret the vector or hash map value as a DSL.

Composite types

Composite types are supported:

(-> (insert-into :comp_table)
    (columns :name :comp_column)
    (values
     [["small" (composite 1 "inch")]
      ["large" (composite 10 "feet")]])
    (sql/format {:pretty true}))
=> ["
INSERT INTO comp_table (name, comp_column)
VALUES (?, (?, ?)), (?, (?, ?))
"
"small" 1 "inch" "large" 10 "feet"]
;; with numbered parameters:
(-> (insert-into :comp_table)
    (columns :name :comp_column)
    (values
     [["small" (composite 1 "inch")]
      ["large" (composite 10 "feet")]])
    (sql/format {:pretty true :numbered true}))
=> ["
INSERT INTO comp_table (name, comp_column)
VALUES ($1, ($2, $3)), ($4, ($5, $6))
"
"small" 1 "inch" "large" 10 "feet"]
;; or as pure data DSL:
(-> {:insert-into [:comp_table],
     :columns [:name :comp_column],
     :values [["small" [:composite 1 "inch"]]
              ["large" [:composite 10 "feet"]]]}
    (sql/format {:pretty true}))
=> ["
INSERT INTO comp_table (name, comp_column)
VALUES (?, (?, ?)), (?, (?, ?))
"
"small" 1 "inch" "large" 10 "feet"]

Updates

Updates are possible too:

(-> (update :films)
    (set {:kind "dramatic"
           :watched [:+ :watched 1]})
    (where [:= :kind "drama"])
    (sql/format {:pretty true}))
=> ["
UPDATE films
SET kind = ?, watched = watched + ?
WHERE kind = ?
"
"dramatic"
1
"drama"]
;; or as pure data DSL:
(-> {:update :films,
     :set {:kind "dramatic", :watched [:+ :watched 1]},
     :where [:= :kind "drama"]}
    (sql/format {:pretty true}))
=> ["
UPDATE films
SET kind = ?, watched = watched + ?
WHERE kind = ?
"
"dramatic"
1
"drama"]

If you are trying to build a compound update statement (with from or join), be aware that different databases have slightly different syntax in terms of where SET should appear. The default above is to put SET before FROM which is how PostgreSQL (and other ANSI-SQL dialects work). If you are using MySQL, you will need to select the :mysql dialect in order to put the SET after any JOIN clause.

Deletes

Deletes look as you would expect:

(-> (delete-from :films)
    (where [:<> :kind "musical"])
    (sql/format))
=> ["DELETE FROM films WHERE kind <> ?" "musical"]
;; or as pure data DSL:
(-> {:delete-from [:films],
     :where [:<> :kind "musical"]}
    (sql/format))
=> ["DELETE FROM films WHERE kind <> ?" "musical"]

If your database supports it, you can also delete from multiple tables:

(-> (delete [:films :directors])
    (from :films)
    (join :directors [:= :films.director_id :directors.id])
    (where [:<> :kind "musical"])
    (sql/format {:pretty true}))
=> ["
DELETE films, directors
FROM films
INNER JOIN directors ON films.director_id = directors.id
WHERE kind <> ?
"
"musical"]
;; or pure data DSL:
(-> {:delete [:films :directors],
     :from [:films],
     :join [:directors [:= :films.director_id :directors.id]],
     :where [:<> :kind "musical"]}
    (sql/format {:pretty true}))
=> ["
DELETE films, directors
FROM films
INNER JOIN directors ON films.director_id = directors.id
WHERE kind <> ?
"
"musical"]

If you want to delete everything from a table, you can use truncate:

(-> (truncate :films)
    (sql/format))
=> ["TRUNCATE TABLE films"]
;; or as pure data DSL:
(-> {:truncate :films}
    (sql/format))
=> ["TRUNCATE TABLE films"]

Set operations

Queries may be combined with a :union, :union-all, :intersect or :except keyword:

(sql/format {:union [(-> (select :*) (from :foo))
                     (-> (select :*) (from :bar))]})
=> ["SELECT * FROM foo UNION SELECT * FROM bar"]

There are also helpers for each of those:

(sql/format (union (-> (select :*) (from :foo))
                   (-> (select :*) (from :bar))))
=> ["SELECT * FROM foo UNION SELECT * FROM bar"]

Note: different databases have different precedence rules for these set operations when used in combination -- you may need to use :nest to add ( .. ) in order to combine these operations in a single SQL statement, if the natural order produced by HoneySQL does not work "as expected" for your database.

Functions

Function calls (and expressions with operators) can be specified as vectors where the first element is either a keyword or a symbol:

(-> (select :*) (from :foo)
    (where [:> :date_created [:date_add [:now] [:interval 24 :hours]]])
    (sql/format))
=> ["SELECT * FROM foo WHERE date_created > DATE_ADD(NOW(), INTERVAL ? HOURS)" 24]

Note: The above example may be specific to MySQL but the general principle of vectors for function calls applies to all dialects.

A shorthand syntax also exists for simple function calls: keywords that begin with % are interpreted as SQL function calls:

(-> (select :%count.*) (from :foo) sql/format)
=> ["SELECT COUNT(*) FROM foo"]
;; with an alias:
(-> (select [:%count.* :total]) (from :foo) sql/format)
=> ["SELECT COUNT(*) AS total FROM foo"]
(-> (select :%max.id) (from :foo) sql/format)
=> ["SELECT MAX(id) FROM foo"]

Since regular function calls are indicated with vectors and so are aliased pairs, this shorthand can be more convenient due to the extra wrapping needed for the regular function calls in a select:

(-> (select [[:count :*]]) (from :foo) sql/format)
=> ["SELECT COUNT(*) FROM foo"]
(-> (select [[:count :*] :total]) (from :foo) sql/format)
=> ["SELECT COUNT(*) AS total FROM foo"]
(-> (select [:%count.*]) (from :foo) sql/format)
=> ["SELECT COUNT(*) FROM foo"]
;; or even:
(-> (select :%count.*) (from :foo) sql/format)
=> ["SELECT COUNT(*) FROM foo"]
(-> (select [[:max :id]]) (from :foo) sql/format)
=> ["SELECT MAX(id) FROM foo"]
(-> (select [[:max :id] :highest]) (from :foo) sql/format)
=> ["SELECT MAX(id) AS highest FROM foo"]
;; the pure data DSL requires an extra level of brackets:
(-> {:select [[[:max :id]]], :from [:foo]} sql/format)
=> ["SELECT MAX(id) FROM foo"]
(-> {:select [[[:max :id] :highest]], :from [:foo]} sql/format)
=> ["SELECT MAX(id) AS highest FROM foo"]
;; the shorthand makes this simpler:
(-> {:select [[:%max.id]], :from [:foo]} sql/format)
=> ["SELECT MAX(id) FROM foo"]
(-> {:select [[:%max.id :highest]], :from [:foo]} sql/format)
=> ["SELECT MAX(id) AS highest FROM foo"]
;; or even (no alias):
(-> {:select [:%max.id], :from [:foo]} sql/format)
=> ["SELECT MAX(id) FROM foo"]
;; or even (no alias, no other columns):
(-> {:select :%max.id, :from :foo} sql/format)
=> ["SELECT MAX(id) FROM foo"]

Custom columns using functions are built with the same vector format. Be sure to properly nest the vectors so that the first element in the selection is the custom function and the second is the column alias.

(sql/format
  {:select   [:job_name                                      ;; A bare field selection
              [[:avg [:/ [:- :end_time :start_time] 1000.0]] ;; A custom function
               :avg_exec_time_seconds                        ;; The column alias
               ]]
   :from     [:job_data]
   :group-by :job_name})
=> ["SELECT job_name, AVG((end_time - start_time) / ?) AS avg_exec_time_seconds FROM job_data GROUP BY job_name" 1000.0]

If a keyword begins with ', the function name is formatted as a SQL entity rather than being converted to uppercase and having hyphens - converted to spaces). That means that hyphens - will become underscores _ unless you have quoting enabled:

(-> (select :*) (from :foo)
    (where [:'my-schema.SomeFunction :bar 0])
    (sql/format))
=> ["SELECT * FROM foo WHERE my_schema.SomeFunction(bar, ?)" 0]
(-> (select :*) (from :foo)
    (where [:'my-schema.SomeFunction :bar 0])
    (sql/format :quoted true))
=> ["SELECT * FROM \"foo\" WHERE \"my-schema\".\"SomeFunction\"(\"bar\", ?)" 0]
(-> (select :*) (from :foo)
    (where [:'my-schema.SomeFunction :bar 0])
    (sql/format :dialect :mysql))
=> ["SELECT * FROM `foo` WHERE `my-schema`.`SomeFunction`(`bar`, ?)" 0]

Note: in non-function contexts, if a keyword begins with ', it is transcribed into the SQL exactly as-is, with no case or character conversion at all.

Bindable parameters

Keywords that begin with ? are interpreted as bindable parameters:

(-> (select :id)
    (from :foo)
    (where [:= :a :?baz])
    (sql/format {:params {:baz "BAZ"}}))
=> ["SELECT id FROM foo WHERE a = ?" "BAZ"]
;; or with numbered parameters:
(-> (select :id)
    (from :foo)
    (where [:= :a :?baz])
    (sql/format {:params {:baz "BAZ"} :numbered true}))
=> ["SELECT id FROM foo WHERE a = $1" "BAZ"]
;; or as pure data DSL:
(-> {:select [:id], :from [:foo], :where [:= :a :?baz]}
    (sql/format {:params {:baz "BAZ"}}))
=> ["SELECT id FROM foo WHERE a = ?" "BAZ"]

Miscellaneous

Sometimes you want to provide SQL fragments directly or have certain values placed into the SQL string rather than turned into a parameter.

The :raw syntax lets you embed SQL fragments directly into a HoneySQL expression. It accepts either a single string to embed or a vector of expressions that will be converted to strings and embedded as a single string.

The :inline syntax attempts to turn a Clojure value into a SQL value and then embeds that string, e.g., [:inline "foo"] produces 'foo' (a SQL string).

The :param syntax identifies a named parameter whose value will be supplied via the :params argument to format.

The :lift syntax will prevent interpretation of Clojure data structures as part of the DSL and instead turn such values into parameters (useful when you want to pass a vector or a hash map directly as a positional parameter value, for example when you have extended next.jdbc's SettableParameter protocol to a data structure -- as is common when working with PostgreSQL's JSON/JSONB types).

Finally, the :nest syntax will cause an extra set of parentheses to be wrapped around its argument, after formatting that argument as a SQL expression.

These can be combined to allow more fine-grained control over SQL generation:

(def call-qualify-map
  (-> (select [[:foo :bar]] [[:raw "@var := foo.bar"]])
      (from :foo)
      (where [:= :a [:param :baz]] [:= :b [:inline 42]])))
call-qualify-map
=> {:where [:and [:= :a [:param :baz]] [:= :b [:inline 42]]]
    :from (:foo)
    :select [[[:foo :bar]] [[:raw "@var := foo.bar"]]]}
(sql/format call-qualify-map {:params {:baz "BAZ"}})
=> ["SELECT FOO(bar), @var := foo.bar FROM foo WHERE (a = ?) AND (b = 42)" "BAZ"]
(-> (select :*)
    (from :foo)
    (where [:< :expired_at [:raw ["now() - '" 5 " seconds'"]]])
    (sql/format))
=> ["SELECT * FROM foo WHERE expired_at < now() - '5 seconds'"]
(-> (select :*)
    (from :foo)
    (where [:< :expired_at [:raw ["now() - '" [:lift 5] " seconds'"]]])
    (sql/format))
=> ["SELECT * FROM foo WHERE expired_at < now() - '? seconds'" 5]
(-> (select :*)
    (from :foo)
    (where [:< :expired_at [:raw ["now() - '" [:param :t] " seconds'"]]])
    (sql/format {:params {:t 5}}))
=> ["SELECT * FROM foo WHERE expired_at < now() - '? seconds'" 5]
(-> (select :*)
    (from :foo)
    (where [:< :expired_at [:raw ["now() - " [:inline (str 5 " seconds")]]]])
    (sql/format))
=> ["SELECT * FROM foo WHERE expired_at < now() - '5 seconds'"]

PostGIS

A common example in the wild is the PostGIS extension to PostgreSQL where you have a lot of function calls needed in code:

(-> (insert-into :sample)
    (values [{:location [:ST_SetSRID
                         [:ST_MakePoint 0.291 32.621]
                         [:cast 4325 :integer]]}])
    (sql/format {:pretty true}))
=> ["
INSERT INTO sample (location)
VALUES (ST_SETSRID(ST_MAKEPOINT(?, ?), CAST(? AS INTEGER)))
"
0.291 32.621 4325]

Entity Names

To quote SQL entity names, pass the :quoted true option to format and they will be quoted according to the selected dialect. If you override the dialect in a format call, by passing the :dialect option, SQL entity names will be automatically quoted. You can override the dialect and turn off quoting by passing :quoted false. Valid :dialect options are :ansi (the default, use this for PostgreSQL), :mysql, :oracle, or :sqlserver. As of 2.5.1091, :nrql is also supported:

(-> (select :foo.a)
    (from :foo)
    (where [:= :foo.a "baz"])
    (sql/format {:dialect :mysql}))
=> ["SELECT `foo`.`a` FROM `foo` WHERE `foo`.`a` = ?" "baz"]
(-> (select :foo.a)
    (from :foo)
    (where [:= :foo.a "baz"])
    (sql/format {:dialect :nrql}))
=> ["SELECT `foo.a` FROM foo WHERE `foo.a` = 'baz'"]

See New Relic NRQL Support for more details of the NRQL dialect.

Locking

The ANSI/PostgreSQL/SQLServer dialects support locking selects via a FOR clause as follows:

  • :for [<lock-strength> <table(s)> <qualifier>] where <lock-strength> is required and may be one of:
    • :update
    • :no-key-update
    • :share
    • :key-share
  • Both <table(s)> and <qualifier> are optional but if present, <table(s)> must either be:
    • a single table name (as a keyword) or
    • a sequence of table names (as keywords)
  • <qualifier> can be :nowait, :wait, :skip-locked etc.

If <table(s)> and <qualifier> are both omitted, you may also omit the [..] and just say :for :update etc.

(-> (select :foo.a)
    (from :foo)
    (where [:= :foo.a "baz"])
    (for :update)
    (sql/format))
=> ["SELECT foo.a FROM foo WHERE foo.a = ? FOR UPDATE" "baz"]

If the :mysql dialect is selected, an additional locking clause is available: :lock :in-share-mode.

(sql/format {:select [:*] :from :foo
             :where [:= :name [:inline "Jones"]]
             :lock [:in-share-mode]}
            {:dialect :mysql :quoted false})
=> ["SELECT * FROM foo WHERE name = 'Jones' LOCK IN SHARE MODE"]

Dashes are allowed in quoted names:

(sql/format
  {:select [:f.foo-id :f.foo-name]
   :from [[:foo-bar :f]]
   :where [:= :f.foo-id 12345]}
  {:quoted true})
=> ["SELECT \"f\".\"foo-id\", \"f\".\"foo-name\" FROM \"foo-bar\" AS \"f\" WHERE \"f\".\"foo-id\" = ?" 12345]

Big, complicated example

Here's a big, complicated query. Note that HoneySQL makes no attempt to verify that your queries make any sense. It merely renders surface syntax.

(def big-complicated-map
  (-> (select-distinct :f.* :b.baz :c.quux [:b.bla "bla-bla"]
                       [[:now]] [[:raw "@x := 10"]])
      (from [:foo :f] [:baz :b])
      (join :draq [:= :f.b :draq.x]
            :eldr [:= :f.e :eldr.t])
      (left-join [:clod :c] [:= :f.a :c.d])
      (right-join :bock [:= :bock.z :c.e])
      (where [:or
               [:and [:= :f.a "bort"] [:not= :b.baz [:param :param1]]]
               [:and [:< 1 2] [:< 2 3]]
               [:in :f.e [1 [:param :param2] 3]]
               [:between :f.e 10 20]])
      (group-by :f.a :c.e)
      (having [:< 0 :f.e])
      (order-by [:b.baz :desc] :c.quux [:f.a :nulls-first])
      (limit 50)
      (offset 10)))
big-complicated-map
=> {:select-distinct [:f.* :b.baz :c.quux [:b.bla "bla-bla"]
                     [[:now]] [[:raw "@x := 10"]]]
    :from [[:foo :f] [:baz :b]]
    :join [:draq [:= :f.b :draq.x]
           :eldr [:= :f.e :eldr.t]]
    :left-join [[:clod :c] [:= :f.a :c.d]]
    :right-join [:bock [:= :bock.z :c.e]]
    :where [:or
             [:and [:= :f.a "bort"] [:not= :b.baz [:param :param1]]]
             [:and [:< 1 2] [:< 2 3]]
             [:in :f.e [1 [:param :param2] 3]]
             [:between :f.e 10 20]]
    :group-by [:f.a :c.e]
    :having [:< 0 :f.e]
    :order-by [[:b.baz :desc] :c.quux [:f.a :nulls-first]]
    :limit 50
    :offset 10}
(sql/format big-complicated-map
            {:params {:param1 "gabba" :param2 2}
             :pretty true})
=> ["
SELECT DISTINCT f.*, b.baz, c.quux, b.bla AS \"bla-bla\", NOW(), @x := 10
FROM foo AS f, baz AS b
INNER JOIN draq ON f.b = draq.x INNER JOIN eldr ON f.e = eldr.t
LEFT JOIN clod AS c ON f.a = c.d
RIGHT JOIN bock ON bock.z = c.e
WHERE ((f.a = ?) AND (b.baz <> ?)) OR ((? < ?) AND (? < ?)) OR (f.e IN (?, ?, ?)) OR f.e BETWEEN ? AND ?
GROUP BY f.a, c.e
HAVING ? < f.e
ORDER BY b.baz DESC, c.quux ASC, f.a NULLS FIRST
LIMIT ?
OFFSET ?
"
"bort" "gabba" 1 2 2 3 1 2 3 10 20 0 50 10]
;; with numbered parameters:
(sql/format big-complicated-map
            {:params {:param1 "gabba" :param2 2}
             :pretty true :numbered true})
=> ["
SELECT DISTINCT f.*, b.baz, c.quux, b.bla AS \"bla-bla\", NOW(), @x := 10
FROM foo AS f, baz AS b
INNER JOIN draq ON f.b = draq.x INNER JOIN eldr ON f.e = eldr.t
LEFT JOIN clod AS c ON f.a = c.d
RIGHT JOIN bock ON bock.z = c.e
WHERE ((f.a = $1) AND (b.baz <> $2)) OR (($3 < $4) AND ($5 < $6)) OR (f.e IN ($7, $8, $9)) OR f.e BETWEEN $10 AND $11
GROUP BY f.a, c.e
HAVING $12 < f.e
ORDER BY b.baz DESC, c.quux ASC, f.a NULLS FIRST
LIMIT $13
OFFSET $14
"
"bort" "gabba" 1 2 2 3 1 2 3 10 20 0 50 10]
;; Printable and readable
(require '[clojure.edn :as edn])

(= big-complicated-map (edn/read-string (pr-str big-complicated-map)))
=> true

Extensibility

Any keyword (or symbol) that appears as the first element of a vector will be treated as a generic function unless it is declared to be an operator or "special syntax". Any keyword (or symbol) that appears as a key in a hash map will be treated as a SQL clause -- and must either be built-in or must be registered as a new clause.

If your database supports <=> as an operator, you can tell HoneySQL about it using the register-op! function (which should be called before the first call to honey.sql/format):

(sql/register-op! :<=>)
;; all operators are assumed to be variadic:
(-> (select :a) (where [:<=> :a "foo"]) sql/format)
=> ["SELECT a WHERE a <=> ?" "foo"]
(-> (select :a) (where [:<=> "food" :a "fool"]) sql/format)
=> ["SELECT a WHERE ? <=> a <=> ?" "food" "fool"]

Sometimes you want an operator to ignore nil clauses (:and and :or are declared that way):

(sql/register-op! :<=> :ignore-nil true)

Or perhaps your database supports syntax like a BETWIXT b AND c, in which case you can use register-fn! to tell HoneySQL about it (again, called before the first call to honey.sql/format):

;; the formatter will be passed your new operator (function) and a
;; sequence of the arguments provided to it (so you can write any arity ops):
(sql/register-fn! :betwixt
                  (fn [op [a b c]]
                    (let [[sql-a & params-a] (sql/format-expr a)
                          [sql-b & params-b] (sql/format-expr b)
                          [sql-c & params-c] (sql/format-expr c)]
                      (-> [(str sql-a " " (sql/sql-kw op) " "
                                sql-b " AND " sql-c)]
                          (c/into params-a)
                          (c/into params-b)
                          (c/into params-c)))))
;; example usage:
(-> (select :a) (where [:betwixt :a 1 10]) sql/format)
=> ["SELECT a WHERE a BETWIXT ? AND ?" 1 10]
;; with numbered parameters:
(-> (select :a) (where [:betwixt :a 1 10]) (sql/format {:numbered true}))
=> ["SELECT a WHERE a BETWIXT $1 AND $2" 1 10]

Note: the generation of positional placeholders (?) or numbered placeholders ($1, $2, etc) is handled automatically by format-expr so you get this behavior "for free" in your extensions, as long as you use the public API for honey.sql. You should avoid writing extensions that generate placeholders directly if you want them to work with numbered parameters.

You can also register SQL clauses, specifying the keyword, the formatting function, and an existing clause that this new clause should be processed before:

;; the formatter will be passed your new clause and the value associated
;; with that clause in the DSL (which is often a sequence but does not
;; need to be -- it can be whatever syntax you desire in the DSL):
(sql/register-clause! :foobar
                      (fn [clause x]
                        (let [[sql & params]
                              (if (ident? x)
                                (sql/format-expr x)
                                (sql/format-dsl x))]
                          (c/into [(str (sql/sql-kw clause) " " sql)] params)))
                      :from) ; SELECT ... FOOBAR ... FROM ...
;; example usage:
(sql/format {:select [:a :b] :foobar :baz})
=> ["SELECT a, b FOOBAR baz"]
(sql/format {:select [:a :b] :foobar {:where [:= :id 1]}})
=> ["SELECT a, b FOOBAR WHERE id = ?" 1]

If you find yourself registering an operator, a function (syntax), or a new clause, consider submitting a pull request to HoneySQL so others can use it, too. If it is dialect-specific, let me know in the pull request.

License

Copyright (c) 2020-2022 Sean Corfield. HoneySQL 1.x was copyright (c) 2012-2020 Justin Kramer and Sean Corfield.

Distributed under the Eclipse Public License, the same as Clojure.

honeysql's People

Contributors

akhudek avatar arichiardi avatar borkdude avatar camsaul avatar cloojure avatar dancek avatar ddellacosta avatar dijonkitchen avatar doffltmiw avatar emidln avatar hlship avatar holyjak avatar jkk avatar john-shaffer avatar joodie avatar jrdoane avatar justindell avatar juvenn avatar kenfehling avatar lread avatar markbastian avatar mawiraike avatar menthalion avatar michaelblume avatar mishok13 avatar p-himik avatar rnewman avatar seancorfield avatar stathissideris avatar visibletrap avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

honeysql's Issues

Automatic dashification/underscorizing

It might be worth calling out in the Readme the fact that honeysql will automatically dashify/underscorize. This caught me off guard, and I'm not sure what I need to do about it. I'm trying to start using honeysql in a project where I am programatically creating tables in Postgres, and to prevent problems with dashes I just quote the column names. Honeysql is underscoring my column names. Is there a way to disable that behavior? I also need Honeysql to quote my unmodified column names. Currently, it is quoting them, but after it has already munged them, which seems a bit counter productive.

insert-into doesn't support NaN values (and other special values)

The problem here is because numbers are simply converted with 'str' and thus the string 'NaN' is inserted verbatim into the insert value list. I'm still looking into this, but it appears that the jdbc insert! function handles NaN values just fine. My current guess is that 'insert!' just parameterizes everything.

Why does honeysql not parameterize numeric values? Are there performance considerations?

Project status

Hi,

I'm curious to know whether this project is currently being maintained -- it's been three months since the last commit and a year since the last release.

Array formatting error

I'm having trouble creating an insert statement with an array and also other stuff.

dev=> (fmt/format {:insert-into :foo :columns [:bar :baz] :values [{:bar [#sql/array ["one" "two" "three"]] :baz "hi"}]})
["INSERT INTO foo (bar, baz) (baz, bar) VALUES (?, ARRAY[?, ?, ?] NULL)" "hi" "one" "two" "three"]

Notice the extra NULL tacked onto the value list, which breaks things. I'll try to look into this a bit deeper when I have some time and see if I can suss out the issue.

how to translate lower((ts_lexize('unaccent'," p "))[1])

Hi,

Very good library, I'm going to use it a lot.

I have played with sql/call and sql/raw trying to translate the expression above.
The problems are

  1. the extra parethesis are necessary and sql/call needs a name/keyword
  2. the [1] is necessary because is a vector, if I inject it using sql/raw inside sql/call there ll be a ',' separating.

What I'm looking for is a way to use honey in cases like this because I want the parameter goodies that honey bring to the table.

That's what I end up using

(defn func-minusc-sem-acento [p]
  (str "lower((ts_lexize('unaccent'," p "))[1])"))

(defn municipio-pelo-nome [connection nome]
  (let [qry (str "select * from ibge_municipio where "
                 (func-minusc-sem-acento "nome") "=" (func-minusc-sem-acento " ? "))
        _ (prn qry)]
    (first
      (jdbc/query connection [qry nome]))))

Lock support

The main readme page gives an example of using locking as (lock {:mode :update}) but this does not work. Experimenting shows that (lock :mode :update) works instead. So it looks like there is a mistake in the documentation.

SQL dialects

Interesting project. Is there a a thought a supporting SQL dialects? What DB's have you been targeting so far?

SELECT DISTINCT foo ON (bar)

I was trying to generate a SELECT DISTINCT ON (bar) foo recently and the only mechanism I could figure out was:

(-> (select :foo)
    (modifiers "DISTINCT ON (bar)")
    (sql/format))

;; => ["SELECT DISTINCT ON (BAR) foo "]

which feels like unintended usage, but at least works (at least because SQL isn't case-sensitive).

Is there a better way to do this, or a straightforward design as a new feature that I could add?

The #sql/array syntax

It's easy to generate an update statement for a SQL array, using the syntax documented in the tests:

dev=> (fmt/format {:update :foo :set {:bar #sql/array ["baz"]}})
["UPDATE foo SET bar = ARRAY[?]" "baz"]

But that doesn't actually work if vector is in a var, which I expect is a common case:

dev=> (def bazzes ["baz"])
#'dev/bazzes
dev=> (fmt/format {:update :foo :set {:bar #sql/array bazzes}})

IllegalArgumentException Don't know how to create ISeq from: clojure.lang.Symbol  
clojure.lang.RT.seqFrom (RT.java:505)

I guess that's a reader macro, so maybe that can't be expected to work with anything but literals.

Anyway, I figured out that you can do this:

dev=> (fmt/format {:update :foo :set {:bar (honeysql.types/array bazzes)}})
["UPDATE foo SET bar = ARRAY[?]" "baz"]

But then I sorta wonder what the the #sql/array syntax is for. If all that's expected behavior, would you accept a PR that changes the test to use the honeysql.types/array function, so users like me don't get confused?

Multiple Join's do not seem to work

https://gist.github.com/SevereOverfl0w/da8298aaa20cd1855c20/acfa98704b7e2ab2f04981c0a46f2d2ed199dfd7 this base, produces incorrect looking SQL, I assume the codebase isn't handling multiple inner joins too well (result of running sql/format against base):

["SELECT * FROM permission INNER JOIN user = permission.user_id ON server((=, permission.server_id, server.id))"]

However, using the helper syntax does work: https://gist.github.com/SevereOverfl0w/da8298aaa20cd1855c20/3d3bb0ff5f32043284a474adf7e4a22d22888b35

DDL plans

Hi, i'm interested in DDL support.

Do you have ideas or plans, how it should look like?

{:create-table :users
  :columns { :name [:serial :primary-key]
                    :email :text}}}

{:alter-table :users
 :add-columns { :password :text}
 :alter-columns {:email {:type :email :default "anonymous"}}
 :drop-columns [:email]}

{:drop-table :users}

issue with custom fn-handler

using

[honeysql "0.6.3"]

I have built a custom fn-handler (mine is slightly different, but can repro with this):

(defmethod fmt/fn-handler "true" [_]
  (str (fmt/to-sql true)))

(defmethod fmt/fn-handler "fun-call"
  [_ name filter] 
 (str name " FILTER " (fmt/to-sql {:where filter}))
  )

But I am seeing odd behavior where my fn-handler appears to not get used when the function is part of an arithmetic operation, but works fine when part of a boolean operation. Am I missing something?

;good
=> (honeysql/format {:where [:and 1 [:fun-call "count(*)" [:true]]]})
["WHERE (1 AND count(*) FILTER (WHERE TRUE))"]
=> (honeysql/format {:where [:or 1 [:fun-call "count(*)" [:true]]]})
["WHERE (1 OR count(*) FILTER (WHERE TRUE))"]

;bad
=> (honeysql/format {:where [:+ 1 [:fun-call "count(*)" [:true]]]})
["WHERE (1 + (fun_call, ?, (true)))" "count(*)"]
=> (honeysql/format {:where [:- 1 [:fun-call "count(*)" [:true]]]})
["WHERE (1 - (fun_call, ?, (true)))" "count(*)"]
=> (honeysql/format {:where [:> 1 [:fun-call "count(*)" [:true]]]})
["WHERE 1 > (fun_call, ?, (true))" "count(*)"]

Appropriate way to write foo_bar::regclass?

What is the best way to write [:= :attrelid (pg/raw (str "'" table_name "'::regclass"))]?

(sql/query db
 (let [table_name "my_table"]
   (pg/format (pg/build {:select [:attnum [:attname "column"]
                                  [(pg/call :format_type :atttypid :atttypmod) "type"]]
                         :from :pg_attribute
                         :where [:and
                                 [:= :attrelid (pg/raw (str "'" table_name "'::regclass"))]
                                 [:> :attnum 0]
                                 [:not :attisdropped]]
                         :order-by [:attnum]}))))

Thanks,
Devin

Support for column names in WITH

At least in PostgreSQL, when creating CTEs with WITH, column names can be passed in (to produce e.g. WITH m (col1, col2) AS VALUES (2,3), (3,4) SELECT col1 FROM m -- or more usefully to pass in multiple columns of data for an UPDATE, in my experience. If I'm understanding honeysql's code correctly this isn't supported, and it'd be useful for it to be!

more INSERT ... SELECT

INSERT INTO where one of the inserted columns is a subquery is supported with :

(-> (insert-into :user_profile_to_role)
      (values [{:user_profile_id user-id
                :role_id         (-> (select :id)
                                     (from :role)
                                     (where [:= :name role-name]))}])

and INSERT INTO where all of the inserted columns match a subquery with (a happy accident ?):

(-> (insert-into [:bar (-> (select :id) (from :role))]))

but i can't figure out a way to to an INSERT...SELECT where the columns to be inserted are specified, e.g.

INSERT INTO foo (id) (SELECT id FROM bar);

is this currently supported, or do i need to wrap the sub-query to match columns with the INSERT INTO table ?

handling of nil argument in merge-where

merge-where with a nil first argument gives a bad result. This will trigger a syntax error when converted to sql:

user=> (merge-where nil [:= :foo 1])
{:where [:and nil [:= :foo 1]]}

Compare this to the result when given an empty map as first argument:

user=> (merge-where {} [:= :foo 1])
{:where [:= :foo 1]}

The IN infix operator does not work with named query parameters

This form doesn't work as expected:

(def hsql {:select [:*] :from [:customers] :where [:in :id :?ids]})
(honeysql.core/format hsql {:ids [1 2 3]}) ; => ["SELECT * FROM customers WHERE (id in ?) " [1 2 3]]

If this were to work, it would have to result in something of the form:

["SELECT * FROM customers WHERE (id IN (?,?,?))" 1 2 3]]

If there's any interest in making this work, I'd be happy to take a stab at it. It's unclear offhand if the current behavior is desirable for some reason though, so I thought I'd ask first.

quoted identifiers should escape their quote character

Quoted identifiers should allow the quoted character within identifier output. This requires that the appropriate quote character be escaped per the type of :quoting.

So, this is what is currently happening:

user=> (-> (sql/build :select (keyword "column_with_\"_double_quote")) (sql/format :quoting :ansi))
["SELECT \"column_with_\"_double_quote\""]

and this is what should happen:

user=> (-> (sql/build :select (keyword "column_with_\"_double_quote")) (sql/format :quoting :ansi))
["SELECT \"column_with_\"\"_double_quote\""]

:ansi should replace " with ""
:mysql should replace backtick with double backtick *
:mssql should replace ] with ]]

  • after a few tries I couldn't get the markdown to render a double back tick right together

Support for multiple vendor-specific features.

It seems to me that the issue of vendor specific support isn't going to go away. There are some developers that want to develop to the lowest common denominator for the best support across as many databases as possible, and others that want to utilize vendor specific functionality to take greater advantage of the tool you have available. The biggest issue is that both of these arguments are perfectly valid which is why these two pull requests are currently in limbo ( #96 and #86 ) and it makes me think that you might just need to cater to both.

What I suggest is instead of providing arguments to the format function and extending multi-methods and protocols directly, is to create a singular "engine" that would get passed to format. Something that describes how HoneySQL should be constructing the query as opposed to having things defined globally.

(def hsql-engine (honeysql.format.standard/engine))
#_(def hsql-engine (honeysql.format.postgresql/engine))
#_(def hsql-engine (honeysql.format.mysql/engine))
;;; etc.

(honeysql.format/format hsql-engine some-query)

Having support for not only SQL standard but, vendor specific functionality might be a valuable tool to have. It could open the possibility of solving the DDL problem which tends to be very vendor specific as well.

I just thought that an issue dedicated to this very idea was in order as most issues and pull requests seem to be geared toward vendor specific functionality or at least functionality that might be supported by some databases but not others.

Support for INSERT using SELECT

I have yet to find a HoneySQL syntax to generate the following:

insert into a-table (col-1, col-2)
values (1234, id)
select id from b-table where name = 'xyz'

For example:

(-> (sql/insert-into :user_profile_to_role)
           (sql/values [{:user_profile_id user-id
                         :role_id         :r.id}])
           (sql/select :r.id)
           (sql/from [:role :r])
           (sql/where [:in :r.name role-names])
           (rc/db-exec conn))

gets all jumbled up, because the SELECT comes before the INSERT INTO.

Loading test/iss_payments_spec.clj... 10:11:41.879 [nREPL-worker-7] ERROR fan.resources.common - Exception executing HoneySQL:
{:where [:in :r.name ["merchant"]],
 :from ([:role :r]),
 :select (:r.id),
 :values [{:user_profile_id 10010, :role_id :r.id}],
 :insert-into :user_profile_to_role}
    java.sql.BatchUpdateException: Batch entry 0 SELECT r.id INSERT INTO user_profile_to_role FROM role r WHERE (r.name in ('merchant')) (user_profile_id, role_id) VALUES (10010, r.id) was aborted.  Call getNextException to see the cause.
        SQLState: "42601"
       errorCode: 0
    updateCounts: []
org.postgresql.util.PSQLException: ERROR: syntax error at or near "INSERT"
                                     Position: 13
              SQLState: "42601"
             errorCode: 0
    serverErrorMessage: #<ServerErrorMessage ERROR: syntax error at or near "INSERT"
                          Position: 13>

Support 'is null' and 'is not null'

Loving this tool - really!

Can you please add support for [:null :a] and [:not-null :a] for building up where clauses. I can of course already do [:= :a null] but as we all know null != null.

Thanks a bunch.

Invalid syntax for inserting from a union query

Inserts that use a union end up with an extra pair of parenthesis (at least for mysql - unsure of how other dbs handle this).

(format 
  (insert-into [[:baz [:id :qux]] {:union [{:select [:*] :from [:bar]} {:select [:*] :from [:foo]}]}]))
;;=> INSERT INTO baz (id, qux) ((SELECT * FROM bar) UNION (SELECT * FROM foo))

The parens around the union are the problem. I'm not familiar enough with the codebase to know what the implications of this change would be, but a fix that worked for me is (in honeysql.format):

(defmethod format-clause :insert-into [[_ table] _]
  (if (and (sequential? table) (sequential? (first table)))
    (let [select-part (second table)
          union? (contains? select-part :union)]
      (str "INSERT INTO "
           (to-sql (ffirst table))
           " (" (comma-join (map to-sql (second (first table)))) ") "
           (if union?
             (binding [*subquery?* false]
               (to-sql select-part))
             (to-sql select-part))))
    (str "INSERT INTO " (to-sql table))))

with that change, inserts w/ unions produce valid sql:

(format 
  (insert-into  [[:baz [:id :qux]] {:union [{:select [:*] :from [:bar]} {:select [:*] :from [:foo]}]}]))
;;=> INSERT INTO baz (id, qux) (SELECT * FROM bar) UNION (SELECT * FROM foo)

Would you like a PR for this or would you prefer a different implementation?

Should (values) quote field names?

Seeing something strange where that if the field names are strings, instead of keywords, they are quoted in the query, making the query invalid.

Intervals and casts

Is there any way to render Postgres style ::interval and other custom types of colums?

i.e.

select cast(sum(duration) as text)::interval from foo;

Which is valid Postgres SQL, but I have no idea how to render it in HoneySQL.

Make clause order extensible

Most aspects of honeysql are extensible through multimethods, but clause order is not. Figure out how to provide a priority number that can be used to position custom clauses relative to each other

Select distinct on is broken

Issue #1 was closed because you can do {:select [(sql/call :distinct-on :x) :y]}, but that generates SQL which is not working in Postgres: select distinct on (x), y. Postgres complains that the comma is invalid syntax.

I wonder if it's still possible to do DISTINCT ON somehow.

Quoted column names

My table has a column called version which (in postgres at least) needs to be quoted in a lot of usages. Since honeysql doesn't quote column names by default, I think the only two options are (sql/raw "\"version\"") or referring to :tablename.version (which is tricky when the table name itself isn't known till runtime). Am I missing anything?

Adding a subquery aliasing example to the doc

First let me thank you for your very nice library. I am in the process of learning Clojure by porting parts of a Python webapp backend I wrote, and I've been drawn to it with arguments like "declarative data manipulation over ORM", "plain data structures over objects", which are exactly in line with how I've been thinking for a while, without being able to really articulate it. In fact Honey SQL seems similar in spirit (although quite superior I think) to my own little module I use to wrap SQL with plain Python data structures (instead of using a full ORM, or even something lower level like SQLAlchemy Core):

https://github.com/cjauvin/little_pger

Anyway, I began using Honey SQL today and one thing I struggled with is how to alias a subquery like this one (although I agree it's not a very good example), which is mandatory for Postgres:

select count(*) from (select * from client) as foo

By fiddling around I've been able to find that this works:

(-> (select :%count.*)
    (from [(-> (select :*)
                (from :client)) "foo"])
    (sql/format))

but I thought it would be useful to have an example in the doc.

Unable to quote function calls

In PostgreSQL, custom functions may be quoted and there are certain characters that require quoting in PostgreSQL (when there are hyphens, upper case letters, symbols, or spaces used in an identifier.) So it may not be unrealistic for me to want generate SQL that looks like this:

SELECT "non-default-schema"."upsert-email-address"('[email protected]');

This is valid PostgreSQL SQL however, the quoting is required because of the existence of special characters (in this case, namely the hyphen.) If I wrote this using HoneySQL I would have done something like this:

(do
  (require 'honeysql.core)
  (def q {:select [(sql/call :non-default-schema.upsert-email-address "[email protected]")]})
  (honeysql.core/format q :quoting :ansi :allow-dashed-names true))

=> ["SELECT non-default-schema.upsert-email-address(?)" "[email protected]"]

As you can see, neither the schema or the function call itself got escaped. I also don't have any mechanism to enable quoting when a SqlCall is used.

I'm not sure if this is PostgreSQL specific functionality but, having control over what exactly gets quoted might be a nice feature to have because there are cases where quoting is not required and others where it is and I'm fairly certain this isn't unique to PostgreSQL (although, behavior between databases might differ.)

The most sensible solution to me seems to create another record for SqlCallQuoted and extending the ToSql protocol to support dispatch on the new SqlCallQuoted record that will do what I'm expecting.

...am I on the right track here, am I over thinking the problem, and is this a bug or expected (and valid,) behavior for HoneySQL given the provided code above?

Case-preserving function calls

In SQL Server, I make C# calls in SELECT and WHERE clauses.
These function names are case sensitive.

It would be handy if fn-handler :default didn't upper-case the name of the op.

Would you be interested in removing the upper-casing, or making it an option?

Single, unaliased sql/raw seems to be broken in 0.6.2

I looked through the commits between 0.6.1 and 0.6.2 and it wasn't obvious to me what would have broken it, but here's the behavior I'm seeing:

(-> (select (sql/raw "1 + 1"))
    (from :foo)
    (sql/format))

;; 0.6.1
;; => ["SELECT 1 + 1 FROM foo"]

;; 0.6.2
;; => ["1 + 1"]

Adding another column or an alias fixes the problem:

(-> (select :a (sql/raw "1 + 1"))
    (from :foo)
    (sql/format))

;; => ["SELECT a, 1 + 1 FROM foo"]

(-> (select [(sql/raw "1 + 1") :a])
    (from :foo)
    (sql/format))

;; => ["SELECT 1 + 1 AS a FROM foo"]

Opt of sub-queries for IPersistentMap in ToSql

Right now, ToSql defines a method (-to-sql [x] ...) that is specified to IPersistentMap in such a way as to prevent passing JSON values with (honeysql.helpers/values [{:my-json-field {:foo "bar"}}]). This is a significant obstacle for me right now. Would a patch that adds an optional second parameter (meaningful to at least the IPersistentMap implementation) be considered?

Next release

I'd like to cut a new release soonish. I'm guessing we want to merge #34 and #43 before we do that. Is there anything else we should try to get in?

Nicer function calling syntax

It would be really cool to use the following convention for function calls:

(-> (select '(now)
            '(count *)
            '(date_format dob "%m/%d/%Y"))
    (from :users))

Support for exists keyword

e.g.

exists ( select 1 from foo )

or

select *
   from foo
 where exists ( select 1
                           from bar where foo.id = bar.foo_id )

Extensible predicates

I'm doing some work with PostgreSQL and relative dates, so I'm creating some queries with clauses like:

[:< :expired_at (raw (format "now() - interval '%d seconds'" seconds))

I'd like to be able to replace those with something like:

[:< :expired_at [:before-now seconds]]

and have that expand to:

expired_at < now() - interval '5 seconds'

I guess this could just be a function that emits a raw, but doesn't seem full in the idiom of HoneySQL.

Support for insert, update and delete

Could you add support for insert, update and delete queries?

I think this library is simple and well aligned with clojure's philosophy, and want to use it instead of korma, which is too much for me. But lacking CUD support is keeping me from switching to this library.

In a multi-column select, apply modifier to only one column

I'd like to generate a query like this:

Select id, max(last_modified)
From some_table
Group by id
Order by max(last_modified)

but doing this with honeysql:

(-> (select :s.id, :s.last_modified)
     (modifiers :max)
     (from [:some_table s])
     (group :s.id)
     (order-by :s.last_modified))

Creates a query like SELECT MAX s.id, s.last_modified...

Is there a way to apply the modifier, in this case max to only one column, in this case last_modified?

Adding ILIKE support

I don't know what's your stance on adding non-standard SQL support, but I would suggest adding PG's ILIKE operator. If not, I know I can always define it myself using defmethod.

Multiple Joins?

How do you do multiple joins of the same type (inner, left, right, etc.)?

settings

@jkk can you make @ddellacosta and I able to see the settings tab on the honeysql repo? I'd really really like to turn on automatic travis builds, and I think I can do that myself with access to settings, but I can't seem to see them right now.

Support for Microsoft SQL Server paging queries

Microsoft SQL Server requires a bit different syntax for paging queries. SQL Server 2005 and 2008 require a pretty ugly syntax that I don't know would be easy to add in to Honey SQL. SQL Server 2012, however, is pretty close to the format in PostgreSQL.

In Honey SQL, :select ... :limit 50 :offset 10 results in SELECT ... LIMIT 50 OFFSET 10.

SQL Server 2012 requires queries in the form SELECT ... OFFSET 10 ROWS FETCH NEXT 50 ROWS ONLY.

Would it be possible to add in handling for this with new helpers in honeysql.helpers/build-clause (possibly :offsetrows and :fetchnext)?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.