HugSQL 查询中的嵌套命名空间键

Question

I have a nested map with namespaced keys like this:

{
  :model.person/primary {:model.person/name "John Smith"}
}

Instead of simpliying this into a flat map I'd like to pass it straight through to a HugSQL function. The docs say HugSQL supports a deep parameter get and namespaced keys but I'm not sure how to combine them.

(hugsql/def-sqlvec-fns-from-string
  "-- :name get_person :? :1
   -- :doc Get a person
   SELECT * FROM person WHERE name = :value:model.person/primary:model.person/name")

Now if I execute the function it generates with my original map I get this:

(get_person-sqlvec {:model.person/primary {:model.person/name "John Smith"}})

Execution error (ExceptionInfo) at hugsql.core/validate-parameters! (core.clj:83).
Parameter Mismatch: :model.person/name parameter data not found.

I would imagine the variable naming convention in the SQL is the source of the problem:

:value:model.person/primary:model.person/name

But I'm not sure what the correct value should be.

Answer 1

First off, the deep parameter get uses . between keys, not : , so that is part of your problem.

However, right now HugSQL only supports one level of qualified keywords -- because there is an inherent ambiguity between . for separating deep parameter get keys and the . that can be part of (qualified) keywords.

You could have where name =:value:model.person/primary.name and then a hash map like {:model.person/primary {:name "John Smith"}}

Or you could have where name =:value:model.person/name and pass {:model.person/name "John Smith"}

HugSQL will need a different syntax to support nested qualified keys (to resolve the . ambiguity). I mentioned Selmer's approach to Curtis Summers, HugSQL's maintainer: using .. to indicate the dot that is part of a keyword, so you could have:

where name =:value:model..person/primary.model..person/name

(that's how Selmer indicates nested qualified keys) but there are backward compatibility issues to consider as well as whether that's a good syntax in the first place (I'm a heavy user of Selmer and I don't like that, but I understand why they did it).