Smart way to get changes on Db table.

[rvk]

Of course you can do that since in SQLite you can query the meta data and take snapshots from that. And I guess that works. SQLite <> IB

You still didn't understand the opening question.

HOW do you determine which FIELD changed when posting a record.

This has nothing to do with snapshots itself. It is about determining WHAT FIELD changed. So the process of determining the changed fields itself.

Can you please explain HOW you can get SQLite to spit out WHICH FIELD has changed??

[Thaddy]

step 1:
Query the metadata:

Code: SQL  [Select][+][-]

1. SELECT name, SQL FROM sqlite_master WHERE TYPE='table' ORDER BY name;

step 2: Create a snapshot from sqlite_master table
step 3: start a new transaction
step 4:

Code: SQL  [Select][+][-]

1.  ALTER COLUMN ... etc whatever colunn you want TO CHANGE

step 5: commit
step 6: take a new snapshot from the  sqlite_master table
step 7: use the same differnce between the two snapshots

It may require to create a new table before the name change that already has the new name and copy all data to the new table. But I guess that should work.

[Zvoni]

step 1:
Query the metadata:

Code: SQL  [Select][+][-]

1. SELECT name, SQL FROM sqlite_master WHERE TYPE='table' ORDER BY name;

step 2: Create a snapshot from sqlite_master table
step 3: start a new transaction
step 4:

Code: SQL  [Select][+][-]

1.  ALTER COLUMN ... etc whatever colunn you want TO CHANGE

step 5: commit
step 6: take a new snapshot from the  sqlite_master table
step 7: use the same differnce between the two snapshots

It may require to create a new table before the name change that already has the new name and copy all data to the new table. But I guess that should work.

Uh, Thaddy,
TS wants to know which Column changed its VALUE, not the Column-Name (or whatever else)

[rvk]

step 4:

Code: SQL  [Select][+][-]

1.  ALTER COLUMN ... etc whatever colunn you want TO CHANGE

You STILL don't understand the question 
Please read the opening question:

after commuting changes, Is there any way to know that only the name field changed.

So TS is after how (s)he can determine the columns of your "etc whatever colunn you want to change" in a 'smart' way.
Nothing else.

[Zvoni]

step 4:

Code: SQL  [Select][+][-]

1.  ALTER COLUMN ... etc whatever colunn you want TO CHANGE

You STILL don't understand the question 
Please read the opening question:

after commuting changes, Is there any way to know that only the name field changed.

So TS is after how (s)he can determine the columns of your "etc whatever colunn you want to change" in a 'smart' way.
Nothing else.

I think Thaddy's confusion comes from the fact, that TS has a column named "name".....

Hello.
Let say that I have an sqlite3 table
Code: Pascal

    t1 (id integer, name varchar(20), address varchar(50) )

[Thaddy]

Would this work, given my first example:

Code: SQL  [Select][+][-]

1. SELECT
2.     CASE WHEN snapshot1.rollno <> snapshot2.rollno THEN 'rollno' ELSE NULL END AS changed_rollno,
3.     CASE WHEN snapshot1.name <> snapshot2.name THEN 'name' ELSE NULL END AS changed_name
4.     FROM snapshot1 JOIN snapshot2 ON snapshot1.primary_key = snapshot2.primary_key;

not able to test now. Will do that later. Note the query can become cumbersome on tables with many fields. You have to repeat the CASE for every field in the table. It should return the changed fields for each row.

[Zvoni]

Would this work, given my first example;

Code: SQL  [Select][+][-]

1. SELECT
2.     CASE WHEN snapshot1.rollno <> snapshot2.rollno THEN 'rollno' ELSE NULL END AS changed_rollno,
3.     CASE WHEN snapshot1.name <> snapshot2.name THEN 'name' ELSE NULL END AS changed_name
4.     FROM snapshot1 JOIN snapshot2 ON snapshot1.primary_key = snapshot2.primary_key;

not able to test now. Will do that later. Note the query can become cumbersome on tables with many fields. You have to repeat the CASE for every field in the table. I should return the changed fields.

Again: Snapshot ONLY WORKS with Journal-mode WAL

Checking for changed VALUE's for a Field is usually done via Auditing-mechanism, which has to be implemented by yourself.
A journal-mode WAL in SQLite is comparable to the binary log in MySQL, but even there a dba can decide: Nope, binary log, only goes back to the last successful Transaction.

That said:
There is only one "smart way" to get what TS wants: Implement an auditing mechanism yourself.
Easily done with Triggers.
Period!
It's not dependant on journal-mode or whatever else, and you're flexible to the nth degree (add/remove columns/tables, whatever, during the lifetime of the program/database)

[Thaddy]

Then it will still work on local databases in wal mode and exclusive locking.

[Zvoni]

Then it will still work on local databases in wal mode and exclusive locking.

True, but you have to ask yourself: What's easier?
Rely on a journal-mode, that might change in the future, or the way i described?

And don't forget: The "journal" is a separate file.....
... i'm doing spring cleaning on my harddrive......
.... what's that? a "journal"? don't need that... let's delete it.....
....
KABOOM

[Thaddy]

well, store the snapshots in a database table?

[Zvoni]

well, store the snapshots in a database table?

quoting myself

There is only one "smart way" to get what TS wants: Implement an auditing mechanism yourself.
Easily done with Triggers.

Still no need for any specific journal-mode
Even works with InMemory-Databases (as "unusual" that might be)