SQLite Forum

Bug: sqldiff --changeset SOME_FILE ... produces 0-length file
Login

Bug: sqldiff --changeset SOME_FILE ... produces 0-length file

(1) By Larry Brasfield (LarryBrasfield) on 2021-02-01 22:27:24 updated by 1.1 [source]

I was testing a local change to sqldiff.c [a] today and noticed that the subject invocation (with ... naming two, differing databases) produced an entirely empty "changeset" file. This is not what the [sqldiff doc](https://sqlite.org/sqldiff.html) indicates should happen. 

[a. The change is to optionally specify some non-PK column(s) that will not participate in the value comparison.  It did not touch the changeset_one_table() function. ]

Of course, wondering how I broke functionality I **tried** to not touch, I ran the "stock" version, one I downloaded as "sqlite-tools-win32-x86-3340100.zip", with the same arguments. It misbehaves the same way. Without the --changeset argument pair, both produce the expected SQL to alter one database to another.

Is this a known non-feature of sqldiff? If so, the doc is wrong. Otherwise this lack of output must be a bug.

Bug: sqldiff --changeset SOME_FILE ... produces 0-length file

(1.1) By Larry Brasfield (LarryBrasfield) on 2021-02-08 00:35:15 edited from 1.0 updated by 1.2 [link] [source]

(Refreshing and clarifying this bug report.)

Recently, I had reason to see what the "--changeset SOME_FILE" option to sqldiff actually does. [a] I ran the "stock" version, one I downloaded as "sqlite-tools-win32-x86-3340100.zip" [b], with this invocation:<code>
  sqldiff --changeset db_1-2_changeset db1.sdb db2.sdb
</code>, where the two .sdb files are different, confirmed by sqldiff's output when the --changeset option is omitted. The result is that db_1-2_changeset is created and left as an empty file. This is not what the [sqldiff doc](https://sqlite.org/sqldiff.html) indicates should happen. Hence, I believe this represents a sqldiff bug.

[a. I had been testing a local change to sqldiff.c and noticed that the subject invocation (with ... naming two, differing databases) produced an entirely empty "changeset" file. The change was to optionally specify some non-PK column(s) that will not participate in the value comparison.  It did not touch the changeset_one_table() function. Of course, wondering how I broke functionality I **tried** to not touch, I ran the "stock" version to see if I had created a bug. ]

[b. I tested sqldiff.exe on an up-to-date Windows 10 machine. ]

Is this 0-length changeset file creation, regardless of database differences, a known non-feature of sqldiff? If so, its doc is wrong. Otherwise this lack of output must be a bug.

DocBug: sqldiff --changeset SOME_FILE ... produces 0-length file

(1.2) By Larry Brasfield (LarryBrasfield) on 2021-02-08 14:38:41 edited from 1.1 [link] [source]

(Refreshing and clarifying this bug report.)

Recently, I had reason to see what the "--changeset SOME_FILE" option to sqldiff actually does. [a] I ran the "stock" version, one I downloaded as "sqlite-tools-win32-x86-3340100.zip" [b], with this invocation: sqldiff --changeset db_1-2_changeset db1.sdb db2.sdb , where the two .sdb files are different, confirmed by sqldiff's output when the --changeset option is omitted. The result is that db_1-2_changeset is created and left as an empty file. This is not what the sqldiff doc indicates should happen. Hence, I believe this represents a sqldiff bug.

[a. I had been testing a local change to sqldiff.c and noticed that the subject invocation (with ... naming two, differing databases) produced an entirely empty "changeset" file. The change was to optionally specify some non-PK column(s) that will not participate in the value comparison. It did not touch the changeset_one_table() function. Of course, wondering how I broke functionality I tried to not touch, I ran the "stock" version to see if I had created a bug. ]

[b. I tested sqldiff.exe on an up-to-date Windows 10 machine. ]

Is this 0-length changeset file creation, regardless of database differences, a known non-feature of sqldiff? If so, its doc is wrong. Otherwise this lack of output must be a bug.

(2) By Dan Kennedy (dan) on 2021-02-08 13:48:45 in reply to 1.1 [link] [source]

I think specifying --changeset causes tables with no explicitly declared primary key to be silently ignored. Rows with NULL values in their primary key fields are also ignored. These are the same limitations as apply to the sessions module.

Does that explain the zero-length output?

I think you're correct that the docs should mention these things.

Dan.

(3) By Larry Brasfield (larrybr) on 2021-02-08 14:31:47 in reply to 2 [link] [source]

Yes, that explains what I saw. Whoda thunk it (from reading the doc)?