Logging the data being updated in Verify Step

[kamalsivalingam]

Hi,

We are using Postgres DB and was trying to integrate Yuniql for data deployment in Azure DevOps. Looks like its working as expected.
However I was wondering if there is a way to log the actual data being updated in Verify step. We use "RETURNING *" at the end of the query to show the data after update. It would be nice to see the results, so we can stop the deployment in case its unintentionally updating lot/all records.

Thanks!

[rdagumampan]

Hi @kamalsivalingam thanks again for the feedback. I have looked into the code and what are the possibilities. As I understand it, you want the results to be printed out into the CLI after each SQL statement is executed. This feels incredibly complex to implement and might not be possible to support in all other platforms. I know for SQL Sever, we can return the data also after insert/update because it maintains a cache table with reserved name INSERTED and UPDATED and this requires implementing a generic data reader that can support whatever table schema.

I so far cannot think of any work around to support you on this. A possibility might be just print out the record count affected after every statement.

[kamalsivalingam]

@rdagumampan Yes, I think just the record count would itself be great. This way, as part of the validate step, we would know how many records are being updated before we run the actual query

[rdagumampan]

@kamalsivalingam, in practice I would not use yuniql verify in production. This is primarily because it relies on the ability of the database platform's transaction log, connection time out and reliability of your network. If the scope of change is big and big transaction log is created to support rollback, it can make your production database unpredictable and subject to unknown side effects.

Instead, I suggest using staging/preprod/replica database to isolate the verification runs.

[pwilliams906]

A possibility might be just print out the record count affected after every statement.

Just to verify: right now, even if scripts "print" (or equivalent) information during the execution of a script, yuniql isn't sending that to stdout, correct? At least with sqlserver, that's been my experience: "throw" messages will make it to the output/log, but "print" doesn't.

[rdagumampan]

@kamalsivalingam, excuse for the delay, got some good time while its Easter off in EU. Here's how it's going to look like in the next release. This fix will also will be available in the nightly build. Watch this issue and will comments when its ready to use. Thanks for reaching out!

@pwilliams906, yuniql is not subscribing to events coming out of the sql/odbc driver. In this feature, we're just counting the record count affected by the sql statement or batch of sql statement. For SQL Server, the PRINT command is exclusively for use when running scripts in SSMS Query Analyzer afaik. HTH

[kamalsivalingam]

@rdagumampan Awesome, this is great. Thanks for considering the suggestion and getting it integrated!

[rdagumampan]

Closed. Released in v1.3.10.
https://github.com/rdagumampan/yuniql/releases/tag/v1.3.10