zshamrock / dynosql Goto Github PK

Test the following characters in the value:
' ,"= between in and or

so to check all the tokens processing are ignored when in the quote.

In RazorSQL they defined the type of the supported SELECT statements, i.e. https://razorsql.com/docs/dynamodb_sql_support.html.

As the first step would be enough to support them as well.

The next step would be to support OR condition in the query.

https://github.com/antlr/grammars-v4/tree/master/plsql

With the SQLite grammar there are difficulties of properly (or at least not obvious) detecting the values in the WHERE condition.

Worth to check whether using the grammar above will make it easier.

In RazorSQL when expanding the tree looks like it makes the sample scan to figure out what are the table's attributes and their types.

Table's primary keys are selected in bold with the corresponding (PK) (for the hash/partition key) and (PK) (FK) (for the range/sort key). And for indexes also in bold, but in different colors with the (I) flag.

• Checkstyle
• JaCoCo
• PMD
• Spotbugs (FindBugs?)

Unless #5 works out, it then looks like I need to try to write my own grammar or check whether any grammar helps to solve the problem.

Also worth to look whether there are tools which provide similar feature (like QueryDSL http://www.querydsl.com/).

select().all() (or select().columns([])).from()[.where([])]

Or something like this.

The corresponding statement in the DynamoDB will be one of the following:

• Contains
• Not contains
• Begins with

Depending on the location of the placeholder.

There are two wildcards used in conjunction with the LIKE operator:

    % - The percent sign represents zero, one, or multiple characters
    _ - The underscore represents a single character

It was told they use the ANTLR as well. Worth to check how.

http://www.jboss.org/teiid/

https://github.com/UBOdin/jsqlparser

Considering how relatively complex WHERE statement could be, i.e. IN, functions, IS NULL, IS NOT NULL, spaces in the string literals, parens, as well as detecting the type of the literal (i.e. number or string) I thought of the different approach of parsing the WHERE statement.

The idea is to parse WHERE condition character by character, identifying the token (also including parens, quotes, commas, etc.) and establish the context, where the action will depend on the current context, i.e. inside the string, or inside the IN, etc.

This also allows to do the validation where knowing the current token we can validate the next token on the list of the supported tokens for the current one. Ex.: IN token expects the next one will be '(', etc.

Hope this allows to resolve all SQL related tickets all at once.

Should they produce the timestamp value in ms?

https://shields.io/

I.e. some of the statements could be grouped by the parens to specify the priority of the operation, so have to handle this accordingly.

Looks like https://dql.readthedocs.io/en/latest/topics/queries/select.html defines the good enough syntax for the SELECT statement, i.e.

SELECT
    [ CONSISTENT ]
    attributes
    FROM tablename
    [ KEYS IN primary_keys | WHERE expression ]
    [ USING index ]
    [ LIMIT limit ]
    [ SCAN LIMIT scan_limit ]
    [ ORDER BY field ]
    [ ASC | DESC ]
    [ THROTTLE throughput ]
    [ SAVE filename]

Although for now would be ok to skip THROTTLE, SAVE and KEYS IN parts.

Parenthesis in the WHERE condition could affect the priority of the conditions. Handle it properly.

Based on the type of the SQL query and as in the DynamoDB everything is based on the Hash/Partition Key and Sort Key, so the corresponding SQL query could result in the Scan operation instead.

Which is then should be guarded by the application property, i.e. whether it accepts the Scan or not. And if so, the size of the "page" per scan.

dynosql.config similar to the https://projectlombok.org/features/configuration.

min, max, count, avg, sum

What will be the corresponding DynamoDB actions?

Depends on #3

• Coveralls https://coveralls.io/
• Coverity Scan https://scan.coverity.com/

Like:

select Date(Timestamp), Reverse(Username), ...