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

Issue 787: enable SQLITE_ENABLE_UPDATE_DELETE_LIMIT #802

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

itizir
Copy link
Contributor

@itizir itizir commented Apr 14, 2020

Since rebuilding the amalgamation from scratch requires the whole ./configure && make thingy, running the upgrade script in go sadly won't do, so I rewrote it in bash.

Oh, just though probably adding a unit test in the go package to check the DELETE with LIMIT works would be good. Done.

Should resolve #787.

@itizir itizir changed the title #787: enable SQLITE_ENABLE_UPDATE_DELETE_LIMIT Issue 787: enable SQLITE_ENABLE_UPDATE_DELETE_LIMIT Apr 14, 2020
@coveralls
Copy link

coveralls commented Apr 14, 2020

Coverage Status

Coverage remained the same at 53.404% when pulling ad7dd67 on itizir:787/delete_limit into aa77c03 on mattn:master.

@itizir
Copy link
Contributor Author

itizir commented Apr 15, 2020

Dammit: libsqlite3 in osx doesn't support that feature, so the test fails in that environment.

@mattn
Copy link
Owner

mattn commented Apr 16, 2020

I wonder the changes for sqlite-binding.c will be updated & reverted with go run upgrade/upgrade.go

@itizir
Copy link
Contributor Author

itizir commented Apr 16, 2020

Oh, is upgrade.go automatically run somewhere? Sorry, I'm not sure I understood what you meant there.
In this PR I suggest replacing the golang upgrade program with a bash script. It does basically the same as upgrade.go (only difference is the newline at the end of sqlite3ext.h: thought I'd keep that consistent...).
But it allows building the amalgamation with custom options, in particular SQLITE_ENABLE_UPDATE_DELETE_LIMIT. I've kept the commits with the switch to bash and with the addition of that flag separate: you should be able to check that without that flag you do get the same bindings as before.

I've now noticed rewriting the upgrade tool had indeed been suggested before: #500 (comment)

If you don't feel comfortable merging in PRs with changes to the bindings directly, I could also remove this part of the change and let you run the updated upgrade script yourself afterwards. Up to you!

@itizir
Copy link
Contributor Author

itizir commented Apr 20, 2020

Hi again! Any thoughts about the change, then? :)

@vzool
Copy link

vzool commented Apr 21, 2020

UP

@mattn
Copy link
Owner

mattn commented May 2, 2020

I don't want to update sqlite3-binding.c directly. So if you want to add this, please update upgrade/upgrad.go to enable you want.

@itizir
Copy link
Contributor Author

itizir commented May 2, 2020

Did I understand this right? You're happy with accepting my change to the upgrade script, but want to run it and commit the bindings changes yourself?

I've removed the changes to sqlite3-binding.c and sqlite3ext.h and added a t.Skip() to the 'delete with limit' test I've added.

Let me know if it's OK now! :)

@mattn
Copy link
Owner

mattn commented May 7, 2020

Thanks. But please keep to write in Go since I want to run this script on Windows too.

@itizir
Copy link
Contributor Author

itizir commented May 7, 2020

I don't think that's possible, sadly. At least I couldn't think of a way to do so (I mean, even a go script would have to either call configure/make or nmake on windows).

EDIT: Hmm, it does look like invoking the build tools from go should work fine. There could then be a separate windows/unix implementation. Would the windows environment indeed have nmake available? I'm not sure I'll manage to test that it works all fine, but can try. Or if I do an initial implementation, would you check if it works as expected?

@itizir
Copy link
Contributor Author

itizir commented May 8, 2020

All right! Here's my attempt at going back to go. I ended up rewriting more of the original upgrade.go than I first thought I would; I hope it's ok.

It does run on Windows as well, provided the right tools are available (nmake + tcl interpreter).

)

func buildAmalgamation(baseDir, buildFlags string) error {
args := []string{"/f", "Makefile.msc", "sqlite3.c"}
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please check "gcc" can be used at the first.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What command should be run if gcc is available? And how should I check if it is?
Sorry, I'm not developing on Windows, so I'm not sure of all the ways to build this, and what the typical toolchains would be.
The only thing I tried was installing Visual Studio and ActiveTcl, and then running the recommended nmake script. This worked for me. I didn't try MinGW or anything like that...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ehm, I was still waiting for some clarifications here...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Still no feedback? :/

Copy link
Owner

@mattn mattn Jun 30, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

MinGW works mostly like UNIX.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for looking at it again!

So does running

$ sh configure
$ make sqlite3.c

work indeed?

In which case should we get rid of upgrade_windows.go altogether?
Or should both ways of building be available, either picked based on some CLI flag, or by trying one and checking for 'executable not found' or something to decide whether it should fall back to the other way?

Copy link
Owner

@mattn mattn Jun 30, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

c:\msys64\usr\bin\bash.exe -c ./configure
c:\msys64\usr\bin\make.exe sqlite3.c

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good. I'll make windows and unix code symmetrical then, simply with default paths to bash and make different (and configurable). And will get rid of nmake, unless you think it's useful to leave it in there?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Is the -c necessary, by the way? Not that it makes much difference... just curious. I will now invoke configure this way indeed, and run bash by default.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey again! Any thoughts about the current implementation? Do you want me to do any more changes?

@itizir
Copy link
Contributor Author

itizir commented May 27, 2020

Hey @mattn! Are you still interested in this change, or should I just close the PR?

@itizir
Copy link
Contributor Author

itizir commented Aug 7, 2020

It's been a while! Any chance you could have another look? :)

Also, maybe #828 should go in first: it's probably easier if I have to fix the rebase rather than the other way around...

@codecov-commenter
Copy link

codecov-commenter commented Sep 2, 2020

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (d9e2789) 46.72% compared to head (e5f99d7) 46.72%.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files
@@           Coverage Diff           @@
##           master     #802   +/-   ##
=======================================
  Coverage   46.72%   46.72%           
=======================================
  Files          12       12           
  Lines        1526     1526           
=======================================
  Hits          713      713           
  Misses        671      671           
  Partials      142      142           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@itizir
Copy link
Contributor Author

itizir commented Sep 2, 2020

It's been a while! Any chance you could have another look? :)

Also, maybe #828 should go in first: it's probably easier if I have to fix the rebase rather than the other way around...

...anyway, so I did rebase on top of #828, assuming you might want that change indeed.

But then frustratingly sqlite decided to now give sha3 instead of sha1, so for a hash check I had to bring non-stdlib-packages back in (and committing the go.sum seems to break non-linux go 1.11 builds...). Let me know what you want to do about that...

@itizir
Copy link
Contributor Author

itizir commented Sep 24, 2020

OK, I see you took a different direction. Updated this PR accordingly. Could you maybe try it out again at some point?

@mattn
Copy link
Owner

mattn commented Oct 7, 2020

I tried to run new upgrade.go but nothing changed.

@itizir
Copy link
Contributor Author

itizir commented Oct 7, 2020

I tried to run new upgrade.go but nothing changed.

🤔 Very strange. You mean it ran with no errors, but the bindings didn't get edited at all??

As comparison, here's the output when I run it:

$  CGO_ENABLED=0 go run -tags=upgrade ./upgrade
Go-SQLite3 Upgrade Tool
Downloading https://www.sqlite.org/2020/sqlite-src-3330000.zip
Download successful and verified hash 2f705bdf760664ce605768af7c2b6b082b99fbb7a3446a3d296a513df15f22a8
Extracted sqlite source to sqlite-src-3330000/
Starting to generate amalgamation with CFLAGS: -DSQLITE_ENABLE_UPDATE_DELETE_LIMIT=1
Ran configure successfully
Ran make successfully
SQLite3 amalgamation built
Merging: ext/userauth/userauth.c into sqlite3-binding.c
Patched: sqlite3.c -> sqlite3-binding.c
Merging: ext/userauth/sqlite3userauth.h into sqlite3-binding.h
Patched: sqlite3.h -> sqlite3-binding.h
Patched: sqlite3ext.h -> sqlite3ext.h
Done patching amalgamation
Cleaning up source: deleting sqlite-src-3330000/

How do you deal with the ignore tag you introduced in #851 by the way? I didn't find any other way than deleting it from the upgrade files to be able to run the tool...

@mattn
Copy link
Owner

mattn commented Oct 7, 2020

Now I exported upgrade package to https://github.com/mattn/go-sqlite3-upgrade

@mattn
Copy link
Owner

mattn commented Oct 7, 2020

I run go-sqlite3-upgrade but nothing changes.

@itizir
Copy link
Contributor Author

itizir commented Oct 7, 2020

Now I exported upgrade package to https://github.com/mattn/go-sqlite3-upgrade
I run go-sqlite3-upgrade but nothing changes.

Oh I see. Well I don't see a branch or something with my changes in the new repository. Did you just copy-paste the changes from my PR locally into your /go-sqlite3-upgrade?

Will you be deprecating the /upgrade folder from this repo entirely? Should I close this PR and make one against https://github.com/mattn/go-sqlite3-upgrade instead?

@mattn
Copy link
Owner

mattn commented Oct 7, 2020

go-sqlite3-upgrade uses the code contained in this pull-request change set. I want to know what is updated and what is needed by this pull-request. Thanks.

@itizir
Copy link
Contributor Author

itizir commented Oct 7, 2020

I'm sorry, I'm still confused. :s
The code I see in go-sqlite3-upgrade is the old one, not the one from this PR. That's why I was asking how you were running things.

@mattn
Copy link
Owner

mattn commented Oct 7, 2020

The code I see in go-sqlite3-upgrade is the old one, not the one from this PR. That's why I was asking how you were running things.

Ooops. Sorry. Could you please send the changes as same as this pull-request?

@itizir
Copy link
Contributor Author

itizir commented Oct 14, 2020

Ooops. Sorry. Could you please send the changes as same as this pull-request?

Did I put the changes in the right place? 🙂

mattn/go-sqlite3-upgrade#1

@mholt
Copy link

mholt commented Dec 11, 2020

Subscribing; anything I can do to help this along?

@itizir
Copy link
Contributor Author

itizir commented Jan 5, 2021

Subscribing; anything I can do to help this along?

Good question... I can't answer it though! 😄

Well, maybe you could also double-check the change for sanity, give feedback if you have any; otherwise it's really up to mattn to find time to review and accept/reject the PR.

@itizir
Copy link
Contributor Author

itizir commented Sep 2, 2022

Pinging again: is this ever going to be of interest, or should I just close and scrap the PR?

@mholt
Copy link

mholt commented Sep 2, 2022

@mattn A good amount of effort and discussion has been put into this PR -- would you be able to take a few minutes to review or approve it? (I don't have any expertise here, but it does seem to be thorough and the code looks pretty clean.)

@itizir
Copy link
Contributor Author

itizir commented Nov 18, 2022

Hi @rittneje! Sorry to ping you, but I thought I'd try to get the ball rolling again here, and you seem to be more actively managing the package now.
Any thoughts on this? Would there still be interest in supporting this, or should I just shelve the change and continue maintaining a private fork indefinitely? (or I suppose until SQLite decides to include this in their published amalgamation by default...)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

How to use SQLITE_ENABLE_UPDATE_DELETE_LIMIT feature
6 participants