Below is a step by step guide to the flow of a CsvSQL SQL command. First will be a description of the process with a data flow afterwards as a visual representation.
When a user enters a command it will follow the following steps:
User enters a command.
Command is checked to see if it is a valid command.
Once a user enters a command this command is then passed onto the init() subprocedure which will determine based on a regular expression pattern match where the command should be sent next. If the command is incorrect the user will be informed with an appropriate error.
Once a command is validated as following the general syntax rules, the command is then passed on to an appropriate subprocedure to perform a more indepth regular expression check.
Each command is passed to a specific subprocedure written for it's particular needs, which will check the command to see if it matches one of several accptable cases. These cases make up the basis for the where_clause and limit.
Once the command passes this second level of testing it is deemed to be valid and is then passed on to a subprocedure which will perform the actual operations required by the command.
Before the command can execute it needs to check if the file the command wants to work on is already open, if not it will open the file for writing. At this stage a backup of the file will be made before any work is carried out.
If the file is already open then we can proceed.
Now that we have validate the command sufficiently, ensured the file was open, and a backup copy made we can progress to running the command on the file.
As you can see from the above the life of a CsvSQL command is one of rigourous testing and validation before it is even allowed to start work on a file. The reasoning for this is that the data being worked on in real life CSV's can often be important "mission critical" information, and ensuring that anything that might affect it is completely correct is a must.
Below you can see a data flow diagram representation of the above process.