Skip to content

Conversation

@anubhavj99
Copy link

Fixes #790.
Developing a query-builder taking guidance from the examples in the issue.

Functions added:

  1. SELECT
  2. WHERE
  3. OPTIONAL
  4. UNION
  5. ORDER BY, GROUP BY
  6. AGGREGATES - (functions)
  7. FILTER - (functions), (operations)
  8. LIMIT, OFFSET
  9. FOR_GRAPH - setting graph for a query using
  10. MOVE, ADD
  11. INSERT, DELETE
  12. NESTED QUERY (example)

anubhavj99 and others added 30 commits May 26, 2020 03:24
…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
… 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.
…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
anubhavj99 and others added 11 commits May 28, 2020 15:47
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
…PTIONAL class, CONDITIONAL_STATEMENT class, FILTER class and FOR_GRAPH class. Usage also added.
@coveralls
Copy link

coveralls commented May 28, 2020

Coverage Status

Coverage increased (+0.4%) to 76.161% when pulling 3e429bd on anubhavj99:Issue790 into 037ea51 on RDFLib:master.

@magdasalatka
Copy link

What's the status? Can we get it merged?

@nicholascar
Copy link
Member

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.

@nicholascar
Copy link
Member

@joernhees I think you might like to review this since you were part of the discussion on Issue #790 that it claims to fix.

@FlorianLudwig
Copy link
Contributor

As commented in the issue (#790 (comment)) I would prefer to have separate QueryBuilders for different query types, e.g.

query = query_builder.Select().where(...)

instead of:

query = query_builder.QueryBuilder.Select().where(...)

As it allows for simplifications in the code and also avoids the question how to handle api usage like:

query = query_builder.QueryBuilder().SELECT(...).INSERT(...)

@FlorianLudwig
Copy link
Contributor

I can see the appeal of the current naming SELECT().WHERE() instead of the pep8 conform .where() but I would like to ask: is that appeal big enough to not follow pep8 as requested in the dev-guide?

With every exception we get further away from doing more linting inside the CI

@ghost ghost added the SPARQL label Feb 12, 2022
@flange-ipb
Copy link

flange-ipb commented May 22, 2024

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

  • group graph pattern
  • UNION
  • OPTIONAL with arbitrary graph pattern
  • VALUES
  • GROUP_CONCAT
  • FILTER (NOT) EXISTS
  • execution of xpath functions

Edit: The query builder implementation in the mentioned project can be found here. Tests are here.

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

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Feature: Query builder.

8 participants