WIP: auto crud

[stambata]

Features:

• possibility to automatically create CRUD procedures based on table definitions.

Fixes:

• move all sql scripts in separate files to reduce risks of conflicts

Notes:

• This is WIP. Only a prototype of the create procedure has been added for now.
• create, read, update and delete procedures are prepared to be generated as per CRUD abbreviations (We might want to stick to our initial idea for add, update, edit, delete, fetch and get)

[stambata]

@kalinkrustev Can you please review the approach? The skeleton is ready.

[kalinkrustev]

Is @result really needed here? Is it needed because of history triggers?

[stambata]

No praticular reason. Just thought that storing the data in a table type would be easier to return all the data as a named resultset at the end.

[kalinkrustev]

Can we discuss if 'data' is good as name? If we call multiple procedures as part of a bigger one, it is better each to return different name for the resultset.

[stambata]

Sure. Instead of 'data' it can be the table name. e.g. 'customer.customer', 'customer.organization', etc.

[kalinkrustev]

Isn't this already a peer dependency of mssql?

[stambata]

It is a dependency of mssql. And I saw it is directly required here so I had to add it to the package.json. If we end up with 2 different versions of tedious that patch won't work.

[kalinkrustev]

Can we also have a generic logic for checking for already existing records and raising standard errors?

[stambata]

Sure, I just wrote some generic SQL code which I didn't mean to be final ... just to test the concept.
We can change the bodies and the names of the procedures however we like. My main idea was to align with you whether the changes in index.js are fine. Maybe @mlessevsg can help with the SQL.

[kalinkrustev]

About naming I am still not sure. If we leave the CRUD naming, then we could have also our current procedures and call the CRUD within them, as the manual ones will probably do some additional actions.