Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
If you enter some data manually into SQLiteStudio and click the commit-button, the data sometimes is silently lost by SQLiteStudio: SQLiteStudio still shows the data, but the data was not committed to the database and disappears after a "refresh".
Maybe this only happens when adding new rows, and maybe only with automatically generated unique ids, but I have not checked this in detail.
Steps to reproduce
After running SQLiteStudio with --debug options, I now have a logfile, and can completely reproduce the issue:
It's unfortunately again caused by SQLiteStudio trying to be smarter than the database... :( I think the SQL-part of SQLiteStudio would need a complete redesign to really solve all these bugs.
SQLiteStudio uses an invalid ROWID when committing data:
SQLiteStudio debug output:
The -1283634412 is wrong here.
This bug alone does not require a SQL-layer redesign. But since it's at least the 5th bug, which results from the same SQLiteStudio-SQL-layer flaw, and since "trying to be smarter than the database" and "guessing values" is never a good idea, I guess that there are quite some more bugs because of this flaw; and the cleanest way to solve them would be to redesign the SQLiteStudio-SQL-layer by doing no "SQL-optimizing" stuff, and simply directly committing the data to the database and directly asking the database for the data.
I know it all seams very simple and easy when looking from outside.
What about editing results of complex query with joins and subqueries? Would you rather refuse it?
Bugs are natural outcome of software development. If particular project can effort dedicated testers and time for developers - they get fixed sooner and software becomes better overall. I simply don't have as much time as I used to. I honestly do hope I will have more time again in some near future, because I did not let this project go yet. I like working on it.
Lastly but not leastly, this particular bug reported above is not related to SQL pre-processing at all. Editing data for simple table (not query results) does not use pre-processing.