Situation

We added a couple new modules (classes) in the course of the refactoring of the query renderer. Those modules need to be listed in the rock spec.

Acceptance Criteria

• All query renderer modules listed in rock spec.

Acceptance Criteria

1. Renders LIMIT clause

Situation

Looks like I overlooked GROUP BY in my feature list.

Acceptance Criteria

• Unit test proves that GROUP BY is rendered correctly.

Error: ] Some problems were encountered while processing the POMs:
[FATAL] Non-readable POM /home/runner/work/virtual-schema-common-lua/virtual-schema-common-lua/pom.xml:
(No such file or directory)

Acceptance criteria

• Each API method of the AbstractVirtualSchemaAdapter has either a default implementation or is an abstract method.

Acceptance Criteria

1. VSCL can render IMPORT statements for EXA-connection-type import

Situation

Virtual Schemas often need properties that act as switches. To avoid code duplication, we need to be able to check if a boolean property is:

• true <-- property set to value true
• false <-- property set to any other value or property not set

Acceptance Criteria

• Property methods isTrue and isFalse supported.

Acceptance Criteria

Renders the following aggregate functions

• APPROXIMATE_COUNT_DISTINCT
• GROUPING / GROUPING_ID

Situation

Currently error message processing is broken in the core database when you use pcall or xpcall (SPOT-13221). Until the fix is available in the core database, we have to live without those.

Acceptance Criteria

• Workaround for xpcall exists.

Prepare release 2.0.0. This is a breaking change, since the new OO-style impacts object creation and initialization calls through the API.

Acceptance Criteria

• GROUP CONCAT rendering supported

Acceptance Criteria

• ExaError updated to 2.0.0 (breaking change)

Situation

We implemented LISTAGG in #19. In the integration test in EVSL we realized that there is a syntax error in the overflow part of the function. It is rendered after instead of inside the parenthesis.

Acceptance Criteria

• LISTAGG syntax adheres to syntax diagram

Summary

When users combine integer constants as expressions with DISTINCT, the engine pushes down GROUP BY <integer-constant>. Exasol interprets this as "group by column number", which yields wrong results. What should happen here is that you get a result with a single group. GROUP BY TRUE, GROUP BY '0' or any other non-integer constant will work as expected.

Note that some databases interpret this as "group by integer constant". So the behavior is database specific. The reason is that this case is not covered by the SQL standard.

Workaround:

The adapter should work around this by turning GROUP BY <integer-constant> into GROUP BY <other-constant>.

Theoretically that should be done on a db-by-db basis, but that is too much effort, so a general workaround in VSCL and VSCJ should be implemented. This can be overridden in the dialect if there is ever the need.

Features

• Turns GROUP BY <integer-constant> into GROUP BY <other-constant>

Acceptance Criteria

1. Render ORDER BY clause

• Create the standard layout of the repository
• Migrate code and tests from exasol/row-level-security-lua
• Refactor for use as library
• Add developer guide

Situation

Currently the Exasol Virtual Schema Lua (EVSL) contains a set of validators that are useful for all Virtual Schemas. They should be moved to the common base library for all VS.

Acceptance Criteria

1. Validators moved
2. Unit tests moved

Situation

To avoid collisions and make checking installations easier, this library needs its unique namespace. Switch to 'exasol.vscl'.

Acceptance Criteria

• Namespace changed from exasolvs to exasol.vscl

Situation

The standard OOP proposed in the Lua books has some problems when you need to safely initialize objects of derived classes, so that the base classes are initialized too. There is a better way using a protected _init method. In the course of using this style, the constructor can and should also take the arguments explicitly instead of a preinitialized object.

Acceptance Criteria

1. Removed create methods
2. new gets explicit parameters
3. Protected _init method

Acceptance Criteria

1. VSCL renders interval literals
2. VSCL renders interval type definitions

Acceptance Criteria

• Model updated with latest changes
• Tracing down to implementation and tests

Situation

I implemented aggregate functions, but forgot to extend the SelectAppender to handle aggregate functions.

Acceptance Criteria

• Test exists for aggregate functions in select list
• Test exists for aggregate functions in where clause

Acceptance Criteria

Readme:

1. Requires Lua 5.4
2. Removes luaunit dependency
3. Adds busted dependency

Acceptance Criteria

1. Use ExaError to generate error messages.

Acceptance Criteria

• Using the rockspec to resolve dependencies is explained.
• EmmyLua is explained for IntelliJ

Acceptance Criteria

Renders the following aggregate functions that have an OVER clause:

• ANY / SOME
• COUNT
• CORR
• COVAR_POP
• COVAR_SAMP
• EVERY
• FIRST_VALUE
• LAST_VALUE
• MAX
• MEDIAN
• MIN
• MUL
• REGR_*
• STDDEV
• STDDEV_POP
• STDSED_SAMP
• SUM
• VAR_POP
• VAR_SAMP
• VARIANCE

Not in scope

• #19
• #50

Done with #69.

Situation

Even with FN_AGG_COUNT + FN_AGG_COUNT_TUPLE activated, we get the following error in the integration test:

Function COUNT should not be called with 2 arguments. Possible number of arguments: 0, 1

Acceptance Criteria

1. Clarify if COUNT(C1, C2) is supposed to work
2. If no: document under "known issues"
3. If yes: fix test and implementation or write ticket to fix VS core

Acceptance Criteria

1. VSCL can render the IS [NOT] JSON predicate

Acceptance criteria

1. ImportBuilder.colum_types takes a table as first argument instead of a list of types as separate arguments
2. If the first argument is 'nil', then the IMPORT is created without the INTO(...) clause
3. If the first argument is an empty table, then the IMPORT is created without the INTO(...) clause

This is a breaking change.

Situation

At the moment the complete SQL rendering is in one large module. This is not sustainable. We need to split the renderer into smaller, more manageable pieces.

Acceptance criteria

1. Renderer split
2. All test still green

Situation

As discussed in exasol/virtual-schema-common-java#247, the API for the set properties request defines that both old an new properties are listed. Since the original API documentation was incomplete, only the old properties are provided through the VSCL interface.

What we need is to

1. Extend the the VSCL interface for the "set property" request with an additional parameter holding the new properties
2. Provide a way to merge both.

Acceptance Criteria

1. "Set properties" request got additional parameter for new properties
2. Adapter properties class has a merge function

This should be automatically added to the board by GitHub automation.

Situation

Currently VSCL ha no CI build. We need one.

Acceptance Criteria

• CI build runs successfully in GHA
• CI build creates a LuaRock

Situation

The tests should also run LuaDoc and the according checks.

Acceptance Criteria

• ImportBuilder included in the package

Acceptance Criteria

1. Renders LISTAGG aggregate function

Acceptance Criteria

1. Change log entry
2. Release data up-to-date
3. Dependencies up-to-date

Acceptance Criteria

1. VSCL renders geospacial functions