Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Querying lore #6

Open
4 tasks
christhompson opened this issue Sep 18, 2016 · 2 comments
Open
4 tasks

Querying lore #6

christhompson opened this issue Sep 18, 2016 · 2 comments

Comments

@christhompson
Copy link
Owner

Ideally, the search functionality should be much richer. The current method (basic keyword search of the "lore" field, optional command line flags to search other fields) is clunky and hard to remember. A better method would be to allow user defined queries on the table. This issue is to track research and steps for designing and implementing this query support.

  • Define the query language. What kinds of queries should we support? What should the syntax be like?
  • Build/configure a parser for the query language.
  • Compile parsed query into a selection expression in our ORM.
  • Write tests???
@christhompson
Copy link
Owner Author

Currently, the best bet I've found is to use a pre-existing query parser (maybe Whoosh), and then recursively compile the parse-tree into peewee Expression nodes.

Using Whoosh would force a specific query language/syntax (roughly like Lucene). Queries would look something like:

(term1 AND term2 OR author:chris) AND rating:>0.75

That's okay, but maybe not ideal. A more natural query language could be better, akin to:

(term1 and term2 or author=chris) and rating>0.75

To make a fully custom query language, we'd need to construct our own parser for it. It looks like the "recommended" simple parser library is pyparsing. The docs are not terribly great, and the included examples are in a random mishmash of licenses (or not licensed at all for reuse), which makes them kind of useless.

@christhompson
Copy link
Owner Author

Related: searching for the blank author (loredb search -a '') doesn't actually work, since it just tries to match the blank string, which is always true.

The new query feature should be rich enough to specify "does not have field X".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant