Fork me on GitHub
#honeysql
<
2022-11-07
>
slipset07:11:28

It seems to me from the examples bit of the https://www.postgresql.org/docs/current/sql-truncate.html that postgres accepts multiple tables to truncate, whereas honey does not?

=# create table t1 (id int);
CREATE TABLE
=# create table t2 (id int);
CREATE TABLE
=# insert into t1 values (1);
INSERT 0 1
=# insert into t2 values (2);
INSERT 0 1
=# select * from t1;
 id
----
  1
(1 row)

=# select * from t2;
 id
----
  2
(1 row)

=# truncate t1, t2;
TRUNCATE TABLE
=# select * from t1;
 id
----
(0 rows)

=# select * from t2;
 id
----
(0 rows)

=#
Is this worth reporting as an issue?

seancorfield08:11:17

Sure, open an issue. I was looking at this just the other day as I extended truncate to support cascade etc. Not sure what the syntax would have to be now, since a sequence argument already means "table + options", but I'll give it some thought.

valerauko15:11:23

does honeysql (2) have some hidden state that persists across calls?

valerauko15:11:18

I'm observing super weird behavior:

user=> (honey.sql/format
  {:replace-into :accounts
   :values [{:public-key 1 :private-key 2}]
   :returning [:*]})
ExceptionInfo These SQL clauses are unknown or have nil values: :replace-into {:replace-into :accounts}
user=> (honey.sql/format
  {:replace-into :accounts
   :values [{:public-key 1 :private-key 2}]
   :returning [:*]}
  {:dialect :mysql
   :quoted-kebab true})
ExceptionInfo These SQL clauses are unknown or have nil values: :replace-into {:replace-into :accounts}
And then suddenly...
user=> (honey.sql/format
  {:replace-into :accounts
   :values [{:public-key 1 :private-key 2}]
   :returning [:*]}
  {:dialect :mysql
   :quoted-kebab true})
["REPLACE INTO `accounts` (`public-key`, `private-key`) VALUES (?, ?) RETURNING *" 1 2]
user=> (honey.sql/format
  {:replace-into :accounts
   :values [{:public-key 1 :private-key 2}]
   :returning [:*]})
["REPLACE INTO accounts (public_key, private_key) VALUES (?, ?) RETURNING *" 1 2]
I thought format was "just" a function but then how come it's not consistent? Does it have some state outside the function for the options?

valerauko15:11:03

Oh okay digging in the source I figured it out. The first time the :mysql dialect is used it adds the clauses globally which means later calls (even if the :dialect passed to format is not :mysql) have access to it. https://github.com/seancorfield/honeysql/blob/23be700b7eb74ff75096bc5c8324634a8e2b9e84/src/honey/sql.cljc#L109

seancorfield18:11:03

Yeah, my feeling with that was that if you use a dialect, it's "harmless" to have any additions it makes stay in play -- if two dialects conflict, selecting back and forth between them should "correct" the formatting anyway. If you are only using one dialect, you probably should set-dialect! at startup. Specifying :dialect in a format call also turns on quoting for that call (unless you also say :quoted false).

valerauko01:11:17

Yeah I can understand that. I think the element that really bugged me was that the first call with :dialect :mysql would fail

seancorfield01:11:17

With? Or without?

valerauko01:11:42

In the example above, it'd fail the first call with :dialect

seancorfield01:11:25

Oh, that's definitely a bug - can you open an issue? I'm on my phone.