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

Add support for using Term as query in run_query() #2796

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

bakaq
Copy link
Contributor

@bakaq bakaq commented Jan 28, 2025

This introduces a feature that was discussed quite a bit before (#2465 (comment), #2500 (reply in thread), #2637 (comment)): using a structured Term instead of a wobbly string for queries. This makes it easier to procedurally generate queries, and also provides a good way to avoid injection attacks.

In the way I implemented, Machine::run_query() can now accept either (things that can be turned into) strings or a Term. A simple example (taken from the tests):

let mut machine = MachineBuilder::default().build();

// X = a.
let query = Term::compound("=", [Term::variable("X"), Term::atom("a")]);

let complete_answer: Vec<_> = machine
    .run_query(query)
    .collect::<Result<_, _>>()
    .unwrap();

assert_eq!(
    complete_answer,
    [LeafAnswer::from_bindings([("X", Term::atom("a"))])]
);

This could get even more ergonomic if we eventually make macros for creating Terms (though I think it would have a lot of limitations on the allowed syntax). Imagine:

let query = term!(X = a);

After doing this I'm really glad we are getting rid of parser::ast::Term in rebis-dev, because that type is a mess! However, from what I've read of the rebis-dev branch, it not existing will probably make this feature a bit harder to implement.

This also serves as even more incentive to base the C embedding interface on a Term based API instead of on top of JSON serialization.

@bakaq bakaq force-pushed the term_query branch 3 times, most recently from 4f92bfe to 0fd36da Compare January 28, 2025 19:00
@jjtolton
Copy link

Anything we can do to prevent string injection would be very welcome for making Scryer an easy choice as a web native language!

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

Successfully merging this pull request may close these issues.

2 participants