Only instead of SQL, you can use stored procedure and you can test them. Store them in migration files or in separate script files referenced by migration which can be version controlled as any other file.
For debugging you debug them, like any other SQL. Normal classic debuggers just won't work with the statement because of the vast difference in paradigm and code execution. SQL is a higher generation programming language that can abstract algorithms, so it can't debugged with step and continue. Just use print statements (or raise debug in Postgres) for procedural code and relay on examination of query results and execution plans.
Hope this helps.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
For unit testing and version control you can use something similar in this article: dev.to/vbilopav/net-identity-with-...
Only instead of SQL, you can use stored procedure and you can test them. Store them in migration files or in separate script files referenced by migration which can be version controlled as any other file.
For debugging you debug them, like any other SQL. Normal classic debuggers just won't work with the statement because of the vast difference in paradigm and code execution. SQL is a higher generation programming language that can abstract algorithms, so it can't debugged with step and continue. Just use print statements (or raise debug in Postgres) for procedural code and relay on examination of query results and execution plans.
Hope this helps.