Spike: Initial Design & Architecture Spike for SQL Support in Script Editor

# **Spike Description**

This spike is for the initial design and architectural thought process around what it will take to add SQL support to the new Script Editor\.

The output expected from this Spike is not any code or working software, but a list of engineering requirements or tasks that is believed will be needed\. That *could* include an architectural design and proposal, or it could simply include the completion of an architectural design and proposal as one of the requirements\/tasks that will be needed to be able to deliver the capability\.

## General Requirements for SQL Support in the Script Editor

The general requirements to consider when thinking about an architecture and design are outlined below\. This is proposed to be in 3 stages, with an MVP being a very rudimentary\/basic implementation, and with step 2 being an upgrade from that and step 3 being much more sophisticated\. Depending on success of phase 1 and 2, we may or may not ever do 3\. These are only suggested phases; if it is easier to do stage 2, for instance directly than have a stage 1 and then a stage 2 \- that is fine and should be considered in the implementation\/design proposal\.

**Phase 1 \- MVP**

- No Schema Browser Integration with Editing Window

- Schema Browser is read only with no checkboxes available for fields or tag values

- No LSP, Simply a blank text window for users to type in a SQL statement

- No Time Range selection, users will have to manually enter the time range they want in their SQL statement

- No validation of their SQL statement ahead of submitting the query

- Scripts can be loaded and saved

- When the run button is selected the entire text\/code block will be encapsulated inside a flux query \(details to be discussed with Nathaniel\)

- Data should be returned from the query in the same format as it is returned today with flux queries, so it is expected that the results window will work exactly like it does today \(note: data may always be pivoted\)

- No function browser will be needed in this case so the right panel can be collapsed\/removed from this view for now

- Choosing SQL from the editor \(vs\. flux\) will be a language selection choice inside the editor

- Any error message returned from the lower level will be shown to the user; however, it is not expected that the area of SQL in failure will be noted \(for syntax, etc\.\)

**Phase 2 \- SQL LSP**

- An open source LSP will be integrated into the solution, allowing the user to have validated syntax and formatting of their SQL statements

**Phase 3 \- Basic SQL Automations**

- Simple SQL Select statements are built based upon schema selections

- Group By is also built into the SQL statement based on Group Settings

- Time Range Selection is integrated into the SQL Statement as well

- SQL Select Statement will always get added with each schema selection set based on the current settings; if user makes a change to the SQL statement, and breaks their script it is ok; if they have two select statements it is ok \- no synchronization is expected \- we may move back to an "inject" button for schema selection for SQL \(topic to be discussed and decided on if we ever move to this phase\)

- A list of SQL functions or other documentation will be held in a right panel \(where flux functions are held\); but no integration\/injection from that panel is expected