-
Notifications
You must be signed in to change notification settings - Fork 580
Fix Issue #790. Adding QueryBuilder. #1090
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
base: main
Are you sure you want to change the base?
Conversation
…der created. 1. Basic Variable class created to handle all the variables. 2. 'Select' Variables read, with aliases as well. 3. 'Where' statements being read as (s, p o).
1. Alias created into a variable before storing into a map.
1. Moved the functionality of WHERE to another function, to be used in optional and union clauses. 2. Method defined to check instance classes of variables passed in the query.
…ion updated to set the query with the optional statements. 1. Example also updated in 'main'.
…h subclass as tuple). 1. Query variable type checking function changed from attribute of QueryBuilder class to function. 2. All statements passed as tuples are transformed to STATEMENT class object. 3. Example updated in main to reflect the above changes.
…ed on the values. 1. Example updated to reflect the same.
…e pending. 1. Example in main updated to reflect the same.
Performed necessary Changes for QueryBuilder class as well
1. Added Alias not supported Exception
… added in "supported_function_expression_list". 1. is_acceptable_query_variable updated to support FUNCTION_EXPR 2. Example updated in main, to reflect the same.
1. Added functionality for passing variables in the functions in both AGGREGATE and FUNCTION_EXPR.
1. Functions added as attributes of class Operators. 2. Symbols like '<', cannot be used, as Variable class has other uses for such operations. 3. Example updated to reflect the same.
1. Removed print statements
…ariable types in WHERE statements.
…of acceptable type. 1. Formatting done for raising Exceptions. 2. Changed from % to format while creating messages.
1. Basic and full query with all functions incorporated. 2. Exceptions generated for: a. without 'where' clause b. incorrect parameter in 'select' c. incorrect tuple size in where clause d. incorrect parameter(s) in where clause e. aggregate with unacceptable variable f. aggregate without alias g. function expr with unacceptable parameters h. filter with unacceptable parameters. i. operands of unacceptable type.
1. Added create_aggregate to create classes for all the different Aggregate functions 2. Added create_function_expr to create classes for all the differnt function expressions
… FOR_GRAPH. Also added INSERT, DELETE and GROUP BY. 1. acceptable variable type changed to any variable having n3() function 2. IN operator added. 3. CONDITIONAL_STATEMENT updated to handle multiple arguments, such as IN 4. Minor bug in FUNCTION_EXPR multiple parameters n3(). Corrected 5. Example also updated
1. Example updated in main.
1. Condition in WHERE function generalized
…lso updated. 1. Kwargs parameter and its usage removed from FOR_GRAPH
1. OR operator, exceptions for insert delete, insert, group by, order by, for graph. 2. Exceptions also added for the same.
1. Move and add queries in query_builder.py 2. Added Test cases in test_issue790.py for move and add
… for various resources.
…PTIONAL class, CONDITIONAL_STATEMENT class, FILTER class and FOR_GRAPH class. Usage also added.
|
What's the status? Can we get it merged? |
|
Hi @anubhavj99 , @Arshdeep25 & @magdasalatka apoligies for missing this PR, I don't know why we haven't addressed it yet. I'm going to put it to multiple review now. |
|
@joernhees I think you might like to review this since you were part of the discussion on Issue #790 that it claims to fix. |
|
As commented in the issue (#790 (comment)) I would prefer to have separate QueryBuilders for different query types, e.g. instead of: As it allows for simplifications in the code and also avoids the question how to handle api usage like: |
|
I can see the appeal of the current naming With every exception we get further away from doing more linting inside the CI |
|
I'd like to emphasize that this is a very valuable contribution. It helped me a lot in one of my recent projects. Thanks @anubhavj99, @Arshdeep25 and @saksham16085! Now, how can we get this into RDFLib? I'd be happy to contribute some additions from my (not yet public) project, such as
Edit: The query builder implementation in the mentioned project can be found here. Tests are here. |
Fixes #790.
Developing a query-builder taking guidance from the examples in the issue.
Functions added: