Search query term changed?

Anki Development
1

hi. i think i used to (programmtically) search with a query term like

-deck:234324 nid:(132343243432,353423555,89235235)

i’ve just upgraded to 2.1.35 (from 2.0? i’m unclear, sadly). i now get an error (see below). in the current docs, i don’t see anything to indicate my above query should work. did it ever work? is there anything similar? from the current docs, i assume i can (nid:234234324 or nid:39457355); is there any siginifcant performance penalty for doing that? i tend to have hundreds if not thousands of terms.

thanks! Q: enjoying rust? cheers, Greg

Traceback (most recent call last):
  File "/home/minshall/usr/bin/bin-scripts/ankiimport", line 480, in <module>
    main()
  File "/home/minshall/usr/bin/bin-scripts/ankiimport", line 475, in main
    doimport(cg.col, args.deckname, ifilepath, str2list(args.mapping),
  File "/home/minshall/usr/bin/bin-scripts/ankiimport", line 429, in doimport
    superset(col, deckname, snids)
  File "/home/minshall/usr/bin/bin-scripts/ankiimport", line 349, in superset
    ids = col.findCards("-deck:%s nid:%s" % (deckname, snids))
  File "/usr/lib/python3.9/site-packages/anki/collection.py", line 450, in find_cards
    return self.backend.search_cards(search=query, order=mode)
  File "/usr/lib/python3.9/site-packages/anki/rsbackend_gen.py", line 82, in search_cards
    output.ParseFromString(self._run_command(9, input))
  File "/usr/lib/python3.9/site-packages/anki/rsbackend.py", line 267, in _run_command
    raise proto_exception_to_native(err)
anki.rsbackend.InvalidInput: Invalid search - please check for typing mistakes.
2

Try without the parentheses. Also, maybe you mean did instead of deck.

2 Likes
3

Rumo, thanks! (the deck was intentional.) i’m curious how you knew the parentheses were incorrect? i.e., if the query is sent to the sql database, are parentheses not allowed there? or, if you know the history, why they worked, why they changed? just curiousity. again, thanks!

4

I’ve spent some times with the parser, therefore I knew that to to the parser, your search would look like "nid:" AND ("132343243432,353423555,89235235"). That is, unquoted parentheses aren’t read literally but are used to isolate groups of search terms.
I’m not aware of a change in the syntax like that and, as you can see, it would have had affected not just nid, but the overall syntax. Then again, 2.0 was some years ago and I probably wouldn’t know.

Curiously, the nid string doesn`t get parsed. There’s just a check whether it’s a comma-separated list of numbers. Then it is passed to SQL like this:

write!(self.sql, "{} in ({})", self.note_id_column(), nids).unwrap();

So for every node there is a check: [the note's id] in ([the list of numbers you passed]).

2 Likes
5

Rumo, thanks very much. cheers.