Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Executing select "with recursion" marks database dirty #1185

Closed
5 of 14 tasks
pamtbaau opened this issue Oct 22, 2017 · 6 comments
Closed
5 of 14 tasks

Executing select "with recursion" marks database dirty #1185

pamtbaau opened this issue Oct 22, 2017 · 6 comments
Assignees
@MKleusberg
Labels
bug Confirmed bugs or reports that are very likely to be bugs.
Milestone
3.11.0 - Where we...

Comments

@pamtbaau
Copy link

Details for the issue

When a select with recursion is executed, the database is marked as dirty.

Useful extra information

I'm opening this issue because:

  • DB4S is crashing
  • DB4S has a bug
  • DB4S needs a feature
  • DB4S has another problem

I'm using DB4S on:

  • Windows: ( version: 10 )
  • Linux: ( distro: ___ )
  • Mac OS: ( version: ___ )
  • Other: ___

I'm using DB4S version:

  • 3.10.1
  • 3.10.0
  • 3.9.1
  • Other: 3.10.99

I have also:
MKleusberg added a commit that referenced this issue Oct 22, 2017
@MKleusberg
Improve detection of query vs. modify statements in Execute SQL tab
a535c37 
This should improve the detection of read-only query statements vs.
modifiying statements in the Execute SQL tab. The idea is to stop
looking for the SELECT keyword at the beginning of the statement and
instead fully rely on whether SQLite returns any data for this
statement.

See issue #1185.
@MKleusberg
Copy link
Member

Good point! I've prepared a patch for this which should fix this. It's replacing a wrong assumption by an untested one. If you want to have a look at this, you can check out this comment: #1181 (comment)

If there are no major concerns with this, we can merge the code in the next couple of days. I'll let you know as soon as this is done 😄

MKleusberg added a commit that referenced this issue Oct 27, 2017
@MKleusberg
Improve detection of query vs. modify statements in Execute SQL tab
3a1eb64 
This should improve the detection of read-only query statements vs.
modifiying statements in the Execute SQL tab. The idea is to stop
looking for the SELECT keyword at the beginning of the statement and
instead fully rely on whether SQLite returns any data for this
statement.

See issue #1185.
MKleusberg added a commit that referenced this issue Oct 27, 2017
@MKleusberg
Improve detection of query vs. modify statements in Execute SQL tab
955848f 
This should improve the detection of read-only query statements vs.
modifiying statements in the Execute SQL tab. The idea is to stop
looking for the SELECT keyword at the beginning of the statement and
instead fully rely on whether SQLite returns any data for this
statement.

See issue #1185.
@MKleusberg
Copy link
Member

And it's merged 😄 Can you test again using tomorrow's nightly build (hopefully the build works this time 😉)? It's also worth checking for any other oddities related to this, like what happens when running other statements.

@pamtbaau
Copy link
Author

pamtbaau commented Oct 28, 2017 •
edited

I would love to test, but again no nightlies for Windows 10 today....

@justinclift
Copy link
Member

justinclift commented Oct 29, 2017 •
edited

@pamtbaau Just started the nightlies build script manually ~5 mins ago, after @MKleusberg fixed the problem that was breaking it.

The now-very-overdue nighlies should be online in ~40 minutes if you're still wanting to test. Or just wait for tomorrows ones which should work ok too. 😄

@pamtbaau
Copy link
Author

Tested build 3.10.99 (version doesn't get bumped anymore) from 29-Oct-2017 18:09 and a recursive query does not mark the database as dirty. Seems to be fixed.

@justinclift
Copy link
Member

Fantastic. Thanks for verifying @pamtbaau. 😄

@justinclift justinclift added bug Confirmed bugs or reports that are very likely to be bugs. and removed response requested labels Oct 29, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@MKleusberg MKleusberg

Labels
bug Confirmed bugs or reports that are very likely to be bugs.
Projects
None yet
Milestone
3.11.0 - Where we take over the world...
Development

No branches or pull requests
3 participants
@justinclift @MKleusberg @pamtbaau