sql 2023-02-07 | Slack Archive

fabrao16:02:06

Hello all, I'm researching for use of Row Level Security (RLS) Policy in Postgres and I'm seeing that we have to use something like set role <role> for restricting the access using a condition defined in that role. Is there any way to "inject" this set role <role> before executing the main query? I don't want to include in all my queries this comand before. Thank you

isak16:02:37

Don't think so. You probably just want to create your own namespace that accesses your DB library (e.g., jdbc), then only use that namespace, and wrap the functions you need like db/execute!.

fabrao16:02:14

what do you mean namespace?

fabrao16:02:33

like in one transaction?

isak16:02:31

Clojure namespace, e.g., myapp.storage.db

emil0r16:02:44

Maybe there is a simple solution I’ve overlooked, but I’m sort of stumped as to what the problem can be. I have a project (called A for short) that uses a library (called L for short) I’ve written that in turn uses next.jdbc. When I’m testing in the library L that is to be consumed everything works as expected. When I try to import it from the project A, I get a weird error from the compile checker, complaining that clojure.java.data/set-properties is not defined as a var. Error is below. I’ve manually checked that the jar is in the repository, and indeed, that set-properties exists in the code at the correct code path, having navigated there from jump to definition when I turned off the loading of the offending code from libraryl L .

clojure.main/message
 "Syntax error compiling at (next/jdbc/connection.clj:435:7).\nNo such var: j/set-properties\n",
 :clojure.main/triage
 {:clojure.error/phase :compile-syntax-check,
  :clojure.error/line 435,
  :clojure.error/column 7,
  :clojure.error/source "connection.clj",
  :clojure.error/path "next/jdbc/connection.clj",
  :clojure.error/class java.lang.RuntimeException,
  :clojure.error/cause "No such var: j/set-properties"},
 :clojure.main/trace
 {:via
  [{:type clojure.lang.Compiler$CompilerException,
    :message
    "Syntax error compiling at (next/jdbc/connection.clj:435:7).",
    :data
    {:clojure.error/phase :compile-syntax-check,
     :clojure.error/line 435,
     :clojure.error/column 7,
     :clojure.error/source "next/jdbc/connection.clj"},
    :at [clojure.lang.Compiler analyze "Compiler.java" 6825]}
   {:type java.lang.RuntimeException,
    :message "No such var: j/set-properties",
    :at [clojure.lang.Util runtimeException "Util.java" 221]}],

Any takers? 🙏:skin-tone-2:

hiredman17:02:38

what cache? cleaned how?

emil0r17:02:30

Lein clean

hiredman17:02:48

my wild guess is something (possibly a badly packaged dependency) is causing another copy of an older version of next.jdbc to be present on the classpath

emil0r17:02:43

I checked that. It's not present. I also included the latest version of clojure.java.data and I get the same problem

emil0r17:02:53

Latest version of clojure

hiredman17:02:07

checked how?

hiredman17:02:34

if it is the result of bad packaging the only way to check is to inspect the jars of your dependencies

hiredman17:02:01

oh, are you using clojurescript?

emil0r17:02:08

Lein deps tree

hiredman17:02:50

lein deps tree tells you what version of each dep is being used, which will be correct as long as all the jars are well packaged

hiredman17:02:40

but if the jars are not well packaged, and random dep D also contains an old version of clojure.java.data, lein deps :tree won't tell you that

hiredman17:02:32

(the reason I asked about clojurescript was for something else, confusing clojure.data.json and cloure.java.data)

emil0r17:02:27

Hmm… gave me an idea

hiredman17:02:57

a big source of badly packaged jars is aot compiling libraries

seancorfield17:02:03

Look for an older version of org.clojure/java.data in transitive dependencies (Leiningen can give you an unexpected older version -- deps.edn/CLI will not: it picks the newer version)

emil0r17:02:52

Removed almost everything in deps, and it compiles now. I’ll hunt down where the problem is

emil0r17:02:56

Found the offending library. Thank you both 🙂

seancorfield17:02:47

Enquiring minds would like to know @U0545PBND!

emil0r20:02:50

It’s a bit of a mindbend. The culprit is this library: https://github.com/magnars/optimus Magnar hasn’t updated the data.java dep. I’ll bother him tomorrow 🙂. However… the library is part of the deps in the project.clj for project A. This is a microservice platform however, and a test library, which itself depends on another microservice in the same ecosystem, also utilizes the same library, and that causes the older version to be used during the compile check. However, if the code that requires it is not loaded in project A, and I manually require data.java in the REPL, I get the old version, but when I navigate to the definitions, it gives me the latest JAR file of data.java

emil0r20:02:14

Updating the library locally and doing a lein install fixes the problem with the cyclic dependency

seancorfield20:02:29

Leiningen's algorithm for selecting a transitive dependency version can be... surprising...

emil0r20:02:17

Indeed 🙂

seancorfield20:02:37

If you have conflicting transitive versions, you basically need to override it explicitly with Leiningen. With deps.edn, you'll get the newer version predictably (unless you explicitly override to an earlier version).

emil0r20:02:04

Noted

emil0r16:02:37

And cache is cleaned. Same problem

2023-02-07

Channels