Fork me on GitHub
#sql
<
2020-08-20
>
p-himik13:08:18

I seem to be hitting some bug in my app that revolves around incorrect application of PostgreSQL transactions. Namely, a before insert trigger does not see rows inserted in a different table in the same transaction prior to firing the trigger. Are there any debugging techniques or tools that could help me? I already log everything, and right before the error it seems that everything just must work. But now, the new rows are invisible.

p-himik14:08:44

Nah, that's just me being dumb, situation normal.

😂 3
kulminaator15:08:51

that's often how it works

kulminaator15:08:09

you ask for someone to look at something and then you discover your own bug

p-himik15:08:15

The yellow duck phenomenon, yeah. Frustrating how just thinking about something can lead you into all sorts of blind spots while coming up with the right words to explain the problem leads you back into the light.

duckie 3
jsyrjala18:08:39

Is it allowed for JDBC ResultSet method getMetaData() return null? I have a JDBC driver (Snowflake) that does it. next-jdbc seems to assume that getMetaData() never returns a null

jsyrjala18:08:47

Specifically net.snowflake.client.jdbc.SnowflakeResultSetV1$EmptyResultSet is implemented like this:

@Override
    public ResultSetMetaData getMetaData() throws SQLException {
      raiseSQLExceptionIfResultSetIsClosed();
      return null;
    }

jsyrjala18:08:35

next.jdbc.result-set function get-column-names breaks on null rsmeta

seancorfield18:08:33

Does it only return null if the result set is empty?

seancorfield18:08:52

(it's certainly not a behavior I've ever seen with any other JDBC driver)

jsyrjala18:08:43

I have not yet tested other cases

jsyrjala18:08:53

I was doing a normal insert

(jdbc/execute-one! db [sql some parameters]
                   {:return-keys ["ID"]})

jsyrjala18:08:09

with autoincrement id field

seancorfield19:08:39

I would have expected that to not return an actual ResultSet at all, and for next.jdbc to then call .getGeneratedKeys which would probably a normal, valid ResultSet for the returned keys.

jsyrjala19:08:53

If i remove the return-keys, I get #:next.jdbc{:update-count 1}

jsyrjala19:08:23

But I have to run now. I’ll look more in to this tomorrow.

seancorfield19:08:26

Maybe Snowflake doesn't support .getGeneratedKeys properly?

jsyrjala19:08:34

that is possible

seancorfield19:08:45

Sounds like it's definitely doing something very unexpected...

seancorfield19:08:14

I updated develop to at least not blow up on the column name function, but I don't know what it will do in your case now...

seancorfield19:08:44

(although that breaks the test suite so I need to double check that)

seancorfield19:08:46

OK, updated to pass the test suite and treat null metadata as "empty" -- let me know how that behaves for you tomorrow (and maybe just try :return-keys true and see what you get?).

jsyrjala20:08:22

@Override
public ResultSet getGeneratedKeys() throws SQLException {
  logger.debug("getGeneratedKeys()");
  raiseSQLExceptionIfStatementIsClosed();
  return new SnowflakeResultSetV1.EmptyResultSet();
}

jsyrjala20:08:49

in SnowflakeStatementV1

jsyrjala20:08:17

so getGeneratedKeys() returns always EmptyResultSet which has null getMetaData()

seancorfield20:08:11

If you're using deps.edn, you can try {:git/url "" :sha "82a62424198b8748d4342c65bcd6881598cc6bc1"} and it should at least not blow up.

seancorfield20:08:50

You will get no columns back tho' (and no rows). So :return-keys just won't work with that driver I suspect.

seancorfield20:08:47

There's probably some other weird, Snowflake-specific ways to get auto-incremented IDs back...?

jsyrjala20:08:43

I actually I don’t even need the auto-increment field. It was just the first thing I tried.

jsyrjala20:08:23

What would be a reasonable/common way for jdbc driver to not to implement getGeneratedKeys()?

jsyrjala20:08:57

It should throw SQLFeatureNotSupportedException

jsyrjala20:08:41

> The Snowflake JDBC driver is a JDBC type 4 driver that supports the core JDBC functionality in version 1.0 of the JDBC API. For the complete API reference, see the http://www.oracle.com/technetwork/java/javase/jdbc/index.html. You are welcome to try methods from later versions of the API, but Snowflake does not guarantee that these methods are supported.

jsyrjala20:08:51

and getGeneratedKeys() is 1.4 version stuff

seancorfield20:08:29

Sounds about right. So they haven't paid attention to detail when implementation some stuff.

seancorfield20:08:45

> Snowflake does not guarantee that these methods are supported ...and they may return unexpected values, rather than throwing SQLFeatureNotSupportedException :rolling_on_the_floor_laughing:

jsyrjala09:08:28

I tested jdbc-next develop branch. Now (jdbc/execute-one! db [sql ..] {:return-keys true}) returns nil, when it previously threw an exception

jsyrjala10:08:04

And I’ll send a bug report to Snowflake about this

3