Fixes parameter after fetch

[Vignesh1-art]

Thank you for submitting this pull request! We really appreciate you spending the time to work on these changes.

What is the motivation?

Parsing fails if variables are encountered after FETCH statement

What does this change do?

Fixes this problem. I have added new parsing function to parse list of variables and Parses it after FETCH statement and implemented to compute variable

What is your testing strategy?

Added unit tests

Is this related to any issues?

#3028

Does this change need documentation?

If this pull request requires changes, updates, or improvements to the documentation, then add a corresponding issue on the docs.surrealdb.com repository, and link to it here.

• No documentation needed

Have you read the Contributing Guidelines?

• I have read the Contributing Guidelines

[Vignesh1-art]

@tobiemh This PR has required test case. Can you please review it.

[Vignesh1-art]

@tobiemh or @DelSkayn someone Please review and approve the workflow

[Vignesh1-art]

I have fixed formatting issues, @tobiemh or @DelSkayn can you please approve the workflow

[Vignesh1-art]

Also @tobiemh or @DelSkayn can you please tell me how to check for formatting issues in local?

[gguillemas]

Hi @Vignesh1-art. We really appreciate your contribution. Please, be patient and do not repeatedly ping people, they have personal lives and can be sick, on holidays or just busy with something else. You can check format locally using cargo fmt --all --check, which will also automatically fix the format if you remove --check.

[Vignesh1-art]

Hi @Vignesh1-art. We really appreciate your contribution. Please, be patient and do not repeatedly ping people, they have personal lives and can be sick, on holidays or just busy with something else. You can check format locally using cargo fmt --all --check, which will also automatically fix the format if you remove --check.

I will take care of it from next time! Thanks @gguillemas, I ran formatting checks in local and now no issues found. If you could approve the workflow please do it.

[Vignesh1-art]

I rebased the branch and did not try to compile it, MIne bad sorry! Now It is working

[tobiemh]

Hi @Vignesh1-art, although this PR works, the way it is implemented probably isn't correct. With this PR, an idiom part can now be a param or a value, meaning that we have to compute a path part, check if it is a string, and process a string as if it is an idiom part. This isn't an ideal way of doing things (although it does work)!

Ideally, we would actually need to accept a Value using parse_value within the try_parse_fetch function in the core/src/syn/parser/stmt/part.rs file:

pub async fn try_parse_fetch(&mut self, ctx: &mut Stk) -> ParseResult<Option<Fetchs>> {
    if !self.eat(t!("FETCH")) {
        return Ok(None);
    }
    let v = self.parse_idiom_list(ctx).await?.into_iter().map(Fetch).collect();
    Ok(Some(Fetchs(v)))
}

And then we would have to change the Fetch type in the core/src/sql/fetch.rs file so that a Fetch is a Value and not an Idiom.

pub struct Fetch(pub Idiom);

Then finally, we would have to ensure that the FETCH clause is computed before being processed.

[Vignesh1-art]

@tobiemh Can you suggest please?

[tobiemh]

Hi @Vignesh1-art changes would need to be made according to this review here: #4086 (comment)

[Vignesh1-art]

@tobiemh Yes i have made changes according that comment, but since I have changed Fetch(Idiom) to Fetch(Value) I can't pass it to compute of fetch statement, because it is of not type Part, mine question is should write logic to convert Value to Part? So logic is

if Value is idiom then
converting to part is straight forward
else
compute Value this will return Strand, Number or Something
Convert that to Part.

Is that correct @tobiemh ?

[DelSkayn]

Adding support for a parameter here doesn't just change the FETCH clause to support params but changes every place where a idiom is allowed which is a lot of places, most of which I am not sure we want to support having parameters in those positions.

Instead of adding support here for parameters I think a better approach would be to implement it in core::syn::parser::stmt::parts::try_parse_fetch. That way the change is limited to just the FETCH clause.