Support relative values (e.g. `resolve-input`) in plugin queries

Advanced queries support relative values. Here the first two inputs are relative:

#+BEGIN_QUERY
{:title "Blocks in 7ds with a page reference of datalog"
 :query [:find (pull ?b [*])
       :in $ ?start ?today ?tag
       :where
       [?b :block/page ?p]
       [?p :page/journal-day ?d]
       [(>= ?d ?start)]
       [(<= ?d ?today)]
       [?b :block/ref-pages ?rp]
       [?rp :block/name ?tag]]
 :inputs [:7d-before :today "datalog"]}
#+END_QUERY

It is not possible to pass relative values (like :today, :7d-before, etc). into queries inside of plugins. In many cases this is not an issue since the developer can compute these values; however, as plugins are JSON configurable by their users (e.g. settings) and JSON doesn’t allow computation, users are unable to pass relative-value queries to plugins they might like to reconfigure.

const ids = await logseq.DB.datascriptQuery(`[:find ?uuid
                :in $ ?start                 
                :where
                [?block :block/uuid ?uuid]
                (or
                  [?block :block/scheduled ?d]
                  [?block :block/deadline ?d])
                [(> ?d ?start)]]`, ":today")

It might even make sense to allow relative values to be embedded directly without declaring inputs:

const ids = await logseq.DB.datascriptQuery(`[:find ?uuid
                :where
                [?block :block/uuid ?uuid]
                (or
                  [?block :block/scheduled ?d]
                  [?block :block/deadline ?d])
                [(> ?d :today)]]`)

As Logseq is already aware of these relative values, why not exposed a tool via the plugin api?

const ids = await logseq.DB.datascriptQuery(`[:find ?uuid
                :in $ ?start                 
                :where
                [?block :block/uuid ?uuid]
                (or
                  [?block :block/scheduled ?d]
                  [?block :block/deadline ?d])
                [(> ?d ?start)]]`, logseq.resolveInput(":today"))

Without it, the plugin developer is left to reimplement relative values or otherwise not allow users to add the most useful kinds of custom queries to their query configurable plugins.

Found this page through google, looking for something related. Fully agree, but this might be better placed in a github issue. It has more eyes on it there.

@Alex_QWxleA - I would have liked to create a github issue, but it’s clear from their submission interface that only bugs can be submitted there and that features must be submitted here. Not sure I could call this a “bug” as much as a glaring omission.

If you click on New Issue, then you end up here, and here you can choose “Feature request” as well. Besides the devs are not too strict about rules. Just be clear in your description. If need be they’ll tell you what to change or add.

Github requests are really the way to go. :+1:

Besides, there is some wonkiness at the moment with [:current-page], etc, so they will have to do some refactoring anyway.

Is this reported to Github issue?
I noticed that the input isn’t work. Although there is a work-around to put the input to the query body directly.
Actually there’s a query resolution logic but it’s not working quite well maybe:

1 Like

Passing inputs via :in doesn’t work for me too. Input put directly in body has no issues:

const query = '[:find (pull ?p[*]) 
  :in $ 
  :where [?pin :block/name "mypage"] 
    [?b :block/refs ?pin] 
    [?b :block/page ?p]]'

logseq.api.datascript_query(query) // results returned

Using :in to pass mypage should be equivalent, but does not work:

const query = '[:find (pull ?p[*]) 
  :in $ ?pname 
  :where [?pin :block/name ?pname] 
    [?b :block/refs ?pin] 
    [?b :block/page ?p]]'

logseq.api.datascript_query(query, "mypage") // empty result

Both examples assume page mypage exists and there is at least one backlink to it.
I could pass custom rules though.