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

Feature: Position/Keyword Args with SQL #33

Open
sjrusso8 opened this issue May 16, 2024 · 4 comments
Open

Feature: Position/Keyword Args with SQL #33

sjrusso8 opened this issue May 16, 2024 · 4 comments
Assignees
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@sjrusso8
Copy link
Owner

Description

Implement the ability to use positional/keyword args with sql. Because of the differences between python and rust, the function arguments need to be clearly implemented.

The pyspark process for sql allows for literals and dataframes to be in one argument. However, rust probably won't take to kindly to that input arg. If a user passes in a DataFrame it will need to be handled with a SubqueryAlias and if it's a literal it will be passed in as either a positional or a keyword argument.

We might want to only allow for to inputs parameters are options. Something like this?

sql<T: ToLiteral>(self, sql_query: &str, col_args: Option<HashMap<String, T>>, df_args: Option<HashMap<String, DataFrame>>) -> DataFrame 

This could allow a user to do these variations.

spark.sql("SELECT * FROM table", None, None).await?;
let df = spark.range(...);

// create the hashmap

spark.sql("SELECT * FROM {df}" None, Some(df_hashmap)).await?;
let col = "name";

// create the hashmap

spark.sql("SELECT {col} FROM {df}", Some(col_hashmap), Some(df_hashmap)).await?;

Or should positional SQL be a completely different method all together? like sql_params? So that a user doesn't need to fuss with adding None x2 to all their sql statements.

@sjrusso8 sjrusso8 added enhancement New feature or request help wanted Extra attention is needed labels May 16, 2024
@hntd187
Copy link
Contributor

hntd187 commented May 17, 2024

The majority of the stuff is probably covered in a format! similar macro, or format_args! some of the other ones with direct DF objects in place may get a bit strange there, but the simple value ones should be easy to do with format and nothing else.

@sjrusso8
Copy link
Owner Author

I’ve haven’t had the time to code it up, but I’m interested in creating a macro like sql! which will handle this. But it’ll also perform similar to what you’d find with the sqlx query! macro that performs validation at compile time.

It would be interesting to have your sql transformation validated by the compiler. I feel like it could be a helpful feature.

@abrassel
Copy link
Contributor

abrassel commented May 25, 2024

Can I take this? I want to try to make the sql! macro. @sjrusso8

@sjrusso8
Copy link
Owner Author

@abrassel go for it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants