aim-sqlite3 2.9.6.1.rc1-x86_64-darwin

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (43) hide show
  1. checksums.yaml +7 -0
  2. data/.gemtest +0 -0
  3. data/CHANGELOG.md +1062 -0
  4. data/CONTRIBUTING.md +130 -0
  5. data/FAQ.md +399 -0
  6. data/INSTALLATION.md +267 -0
  7. data/LICENSE +23 -0
  8. data/README.md +218 -0
  9. data/dependencies.yml +13 -0
  10. data/ext/sqlite3/aggregator.c +314 -0
  11. data/ext/sqlite3/aggregator.h +14 -0
  12. data/ext/sqlite3/backup.c +190 -0
  13. data/ext/sqlite3/backup.h +15 -0
  14. data/ext/sqlite3/database.c +1263 -0
  15. data/ext/sqlite3/database.h +36 -0
  16. data/ext/sqlite3/exception.c +122 -0
  17. data/ext/sqlite3/exception.h +12 -0
  18. data/ext/sqlite3/extconf.rb +299 -0
  19. data/ext/sqlite3/gvl.c +88 -0
  20. data/ext/sqlite3/gvl.h +15 -0
  21. data/ext/sqlite3/sqlite3.c +225 -0
  22. data/ext/sqlite3/sqlite3_ruby.h +49 -0
  23. data/ext/sqlite3/statement.c +755 -0
  24. data/ext/sqlite3/statement.h +17 -0
  25. data/ext/sqlite3/timespec.h +20 -0
  26. data/lib/sqlite3/3.2/sqlite3_native.bundle +0 -0
  27. data/lib/sqlite3/3.3/sqlite3_native.bundle +0 -0
  28. data/lib/sqlite3/3.4/sqlite3_native.bundle +0 -0
  29. data/lib/sqlite3/4.0/sqlite3_native.bundle +0 -0
  30. data/lib/sqlite3/cli.rb +8 -0
  31. data/lib/sqlite3/constants.rb +198 -0
  32. data/lib/sqlite3/database.rb +798 -0
  33. data/lib/sqlite3/errors.rb +88 -0
  34. data/lib/sqlite3/fork_safety.rb +66 -0
  35. data/lib/sqlite3/pragmas.rb +648 -0
  36. data/lib/sqlite3/resultset.rb +96 -0
  37. data/lib/sqlite3/statement.rb +208 -0
  38. data/lib/sqlite3/value.rb +54 -0
  39. data/lib/sqlite3/version.rb +4 -0
  40. data/lib/sqlite3/version_info.rb +17 -0
  41. data/lib/sqlite3.rb +20 -0
  42. data/ports/x86_64-apple-darwin20.2/sqlite3/3.53.2/bin/sqlite3 +0 -0
  43. metadata +105 -0
data/CONTRIBUTING.md ADDED
@@ -0,0 +1,130 @@
1
+ # Contributing to sqlite3-ruby
2
+
3
+ **This document is a work-in-progress.**
4
+
5
+ This doc is a short introduction on how to modify and maintain the sqlite3-ruby gem.
6
+
7
+
8
+ ## Architecture notes
9
+
10
+ ### Decision record
11
+
12
+ As of 2024-09, we're starting to keep some architecture decisions in the subdirectory `/adr`, so
13
+ please look there for additional information.
14
+
15
+ ### Garbage collection
16
+
17
+ All statements keep pointers back to their respective database connections.
18
+ The `@connection` instance variable on the `Statement` handle keeps the database
19
+ connection alive.
20
+
21
+ We use `sqlite3_close_v2` in `Database#close` since v2.1.0 which defers _actually_ closing the
22
+ connection and freeing the underlying memory until all open statements are closed; though the
23
+ `Database` object will immediately behave as though it's been fully closed. If a Database is not
24
+ explicitly closed, it will be closed when it is GCed.
25
+
26
+ `Statement#close` finalizes the underlying statement. If a Statement is not explicitly closed, it
27
+ will be closed/finalized when it is GCed.
28
+
29
+
30
+ ## Debugging memory issues
31
+
32
+ Please install `valgrind` and `gdb` before you use the tools in this section.
33
+
34
+ Run the test suite under valgrind and [`ruby_memcheck`](https://github.com/Shopify/ruby_memcheck) to
35
+ look for memory leaks and other memory errors:
36
+
37
+ ``` sh
38
+ bundle exec rake compile test:valgrind
39
+ ```
40
+
41
+ If you can't install valgrind on your system, use the `sqlite3-dev` docker image, which contains
42
+ valgrind:
43
+
44
+ ``` sh
45
+ # build the image
46
+ bundle exec rake docker:dev:build
47
+
48
+ # run the test suite in a container
49
+ bundle exec rake docker:dev:test
50
+
51
+ # run the test suite under valgrind in a container
52
+ bundle exec rake docker:dev:test:valgrind
53
+ ```
54
+
55
+ Each `docker:dev:test` task builds the image first, then mounts your working copy at `/sqlite3` in
56
+ the container. Note that the container compiles into the mounted working copy, so please re-run
57
+ `rake compile` on your machine afterwards.
58
+
59
+ Run the test suite in the debugger:
60
+
61
+ ``` sh
62
+ bundle exec rake compile test:gdb
63
+ ```
64
+
65
+ You can also run the test suite with a variety of GC behaviors, which is useful to localize some
66
+ classes of memory bugs. Set the `SQLITE3_TEST_GC_LEVEL` environment variable (see `test/helper.rb`
67
+ for more info). A more stressful level finds more bugs, but makes the suite slower:
68
+
69
+ ``` sh
70
+ # ordinary GC behavior (the default)
71
+ SQLITE3_TEST_GC_LEVEL=normal bundle exec rake compile test
72
+
73
+ # minor GC after each test
74
+ SQLITE3_TEST_GC_LEVEL=minor bundle exec rake compile test
75
+
76
+ # major GC after each test
77
+ SQLITE3_TEST_GC_LEVEL=major bundle exec rake compile test
78
+
79
+ # major GC after each test, and GC compaction after every 20 tests
80
+ SQLITE3_TEST_GC_LEVEL=compact bundle exec rake compile test
81
+
82
+ # verify references after compaction, after every 20 tests
83
+ # (see https://alanwu.space/post/check-compaction/)
84
+ SQLITE3_TEST_GC_LEVEL=verify bundle exec rake compile test
85
+
86
+ # run each test with GC "stress mode" on
87
+ SQLITE3_TEST_GC_LEVEL=stress bundle exec rake compile test
88
+ ```
89
+
90
+ The `compact` and `verify` levels fall back to `normal` on a platform that does not support GC
91
+ compaction. The `stress` level makes the suite about 150 times slower, and it makes
92
+ timing-sensitive tests unreliable.
93
+
94
+
95
+ ## Building gems
96
+
97
+ As a prerequisite please make sure you have `docker` correctly installed, so that you're able to cross-compile the native gems.
98
+
99
+ Run `bin/build-gems` which will package gems for all supported platforms, and run some basic sanity tests on those packages using `bin/test-gem-set` and `bin/test-gem-file-contents`.
100
+
101
+
102
+ ## Updating the version of libsqlite3
103
+
104
+ Update `/dependencies.yml` to reflect:
105
+
106
+ - the version of libsqlite3
107
+ - the URL from which to download
108
+ - the checksum of the file, which will need to be verified manually (see comments in that file)
109
+
110
+
111
+ ## Making a release
112
+
113
+ A quick checklist to cutting a release of the sqlite3 gem:
114
+
115
+ Prep
116
+ - [ ] Make sure CI is green!
117
+ - [ ] Update `CHANGELOG.md` and `lib/sqlite3/version.rb`
118
+ - [ ] Create a git tag using a format that matches the pattern `v\d+\.\d+\.\d+`, e.g. `v1.3.13`
119
+ - [ ] `git push && git push --tags`
120
+
121
+ Automated build and release
122
+ - [ ] Run workflow https://github.com/sparklemotion/sqlite3-ruby/actions/workflows/release.yml
123
+ - [ ] Copy checksums from the push job
124
+
125
+ Manual build and release
126
+ - [ ] Run `bin/build-gems` and make sure it completes and all the tests pass
127
+ - [ ] `for g in gems/*.gem ; do gem push $g ; done`
128
+
129
+ Post-release
130
+ - [ ] Create a release at https://github.com/sparklemotion/sqlite3-ruby/releases and include sha2 checksums
data/FAQ.md ADDED
@@ -0,0 +1,399 @@
1
+
2
+ ## How do I do a database query?
3
+ ### I just want an array of the rows...
4
+
5
+ Use the `Database#execute` method. If you don't give it a block, it will
6
+ return an array of all the rows:
7
+
8
+ ```ruby
9
+ require 'sqlite3'
10
+
11
+ db = SQLite3::Database.new( "test.db" )
12
+ rows = db.execute( "select * from test" )
13
+ ```
14
+
15
+ ### I'd like to use a block to iterate through the rows...
16
+
17
+ Use the `Database#execute` method. If you give it a block, each row of the
18
+ result will be yielded to the block:
19
+
20
+
21
+ ```ruby
22
+ require 'sqlite3'
23
+
24
+ db = SQLite3::Database.new( "test.db" )
25
+ db.execute( "select * from test" ) do |row|
26
+ ...
27
+ end
28
+ ```
29
+
30
+ ### I need to get the column names as well as the rows...
31
+
32
+ Use the `Database#execute2` method. This works just like `Database#execute`;
33
+ if you don't give it a block, it returns an array of rows; otherwise, it
34
+ will yield each row to the block. _However_, the first row returned is
35
+ always an array of the column names from the query:
36
+
37
+
38
+ ```ruby
39
+ require 'sqlite3'
40
+
41
+ db = SQLite3::Database.new( "test.db" )
42
+ columns, *rows = db.execute2( "select * from test" )
43
+
44
+ # or use a block:
45
+
46
+ columns = nil
47
+ db.execute2( "select * from test" ) do |row|
48
+ if columns.nil?
49
+ columns = row
50
+ else
51
+ # process row
52
+ end
53
+ end
54
+ ```
55
+
56
+ ### I just want the first row of the result set...
57
+
58
+ Easy. Just call `Database#get_first_row`:
59
+
60
+
61
+ ```ruby
62
+ row = db.get_first_row( "select * from table" )
63
+ ```
64
+
65
+
66
+ This also supports bind variables, just like `Database#execute`
67
+ and friends.
68
+
69
+ ### I just want the first value of the first row of the result set...
70
+
71
+ Also easy. Just call `Database#get_first_value`:
72
+
73
+
74
+ ```ruby
75
+ count = db.get_first_value( "select count(*) from table" )
76
+ ```
77
+
78
+
79
+ This also supports bind variables, just like `Database#execute`
80
+ and friends.
81
+
82
+ ## How do I prepare a statement for repeated execution?
83
+
84
+ If the same statement is going to be executed repeatedly, you can speed
85
+ things up a bit by _preparing_ the statement. You do this via the
86
+ `Database#prepare` method. It returns a `Statement` object, and you can
87
+ then invoke `#execute` on that to get the `ResultSet`:
88
+
89
+
90
+ ```ruby
91
+ stmt = db.prepare( "select * from person" )
92
+
93
+ 1000.times do
94
+ stmt.execute do |result|
95
+ ...
96
+ end
97
+ end
98
+
99
+ stmt.close
100
+
101
+ # or, use a block
102
+
103
+ db.prepare( "select * from person" ) do |stmt|
104
+ 1000.times do
105
+ stmt.execute do |result|
106
+ ...
107
+ end
108
+ end
109
+ end
110
+ ```
111
+
112
+
113
+ This is made more useful by the ability to bind variables to placeholders
114
+ via the `Statement#bind_param` and `Statement#bind_params` methods. (See the
115
+ next FAQ for details.)
116
+
117
+ ## How do I use placeholders in an SQL statement?
118
+
119
+ Placeholders in an SQL statement take any of the following formats:
120
+
121
+
122
+ * `?`
123
+ * `?_nnn_`
124
+ * `:_word_`
125
+ * `$_word_`
126
+ * `@_word_`
127
+
128
+
129
+ Where _n_ is an integer, and _word_ is an alpha-numeric identifier(or number).
130
+ When the placeholder is associated with a number (only in case of `?_nnn_`),
131
+ that number identifies the index of the bind variable to replace it with.
132
+ When it is an identifier, it identifies the name of the corresponding bind
133
+ variable. (In the instance of the first format--a single question mark--the
134
+ placeholder is assigned a number one greater than the last index used, or 1
135
+ if it is the first.)
136
+
137
+
138
+ For example, here is a query using these placeholder formats:
139
+
140
+
141
+ ```sql
142
+ select *
143
+ from table
144
+ where ( c = ?2 or c = ? )
145
+ and d = :name
146
+ and e = :1
147
+ ```
148
+
149
+
150
+ This defines 5 different placeholders: 1, 2, 3, and "name".
151
+
152
+
153
+ You replace these placeholders by _binding_ them to values. This can be
154
+ accomplished in a variety of ways.
155
+
156
+
157
+ The `Database#execute`, and `Database#execute2` methods all accept additional
158
+ arguments following the SQL statement. These arguments are assumed to be
159
+ bind parameters, and they are bound (positionally) to their corresponding
160
+ placeholders:
161
+
162
+
163
+ ```ruby
164
+ db.execute( "select * from table where a = ? and b = ?",
165
+ "hello",
166
+ "world" )
167
+ ```
168
+
169
+
170
+ The above would replace the first question mark with 'hello' and the
171
+ second with 'world'. If the placeholders have an explicit index given, they
172
+ will be replaced with the bind parameter at that index (1-based).
173
+
174
+
175
+ If a Hash is given as a bind parameter, then its key/value pairs are bound
176
+ to the placeholders. This is how you bind by name:
177
+
178
+
179
+ ```ruby
180
+ db.execute( "select * from table where a = :name and b = :value",
181
+ "name" => "bob",
182
+ "value" => "priceless" )
183
+ ```
184
+
185
+
186
+ You can also bind explicitly using the `Statement` object itself. Just pass
187
+ additional parameters to the `Statement#execute` statement:
188
+
189
+
190
+ ```ruby
191
+ db.prepare( "select * from table where a = :name and b = ?" ) do |stmt|
192
+ stmt.execute "value", "name" => "bob"
193
+ end
194
+ ```
195
+
196
+
197
+ Or do a `Database#prepare` to get the `Statement`, and then use either
198
+ `Statement#bind_param` or `Statement#bind_params`:
199
+
200
+
201
+ ```ruby
202
+ stmt = db.prepare( "select * from table where a = :name and b = ?" )
203
+
204
+ stmt.bind_param( "name", "bob" )
205
+ stmt.bind_param( 1, "value" )
206
+
207
+ # or
208
+
209
+ stmt.bind_params( "value", "name" => "bob" )
210
+ ```
211
+
212
+ ## How do I discover metadata about a query result?
213
+
214
+ IMPORTANT: `Database#execute` returns an Array of Array of Strings
215
+ which will have no metadata about the query or the result, such
216
+ as column names.
217
+
218
+
219
+ There are 2 main sources of query metadata:
220
+
221
+ * `Statement`
222
+ * `ResultSet`
223
+
224
+
225
+ You can get a `Statement` via `Database#prepare`, and you can get
226
+ a `ResultSet` via `Statement#execute` or `Database#query`.
227
+
228
+
229
+ ```ruby
230
+ sql = 'select * from table'
231
+
232
+ # No metadata
233
+ rows = db.execute(sql)
234
+ rows.class # => Array, no metadata
235
+ rows.first.class # => Array, no metadata
236
+ rows.first.first.class #=> String, no metadata
237
+
238
+ # Statement has metadata
239
+ stmt = db.prepare(sql)
240
+ stmt.columns # => [ ... ]
241
+ stmt.types # => [ ... ]
242
+
243
+ # ResultSet has metadata
244
+ results = stmt.execute
245
+ results.columns # => [ ... ]
246
+ results.types # => [ ... ]
247
+
248
+ # ResultSet has metadata
249
+ results = db.query(sql)
250
+ results.columns # => [ ... ]
251
+ results.types # => [ ... ]
252
+ ```
253
+
254
+ ## I'd like the rows to be indexible by column name.
255
+
256
+ By default, each row from a query is returned as an `Array` of values. This
257
+ means that you can only obtain values by their index. Sometimes, however,
258
+ you would like to obtain values by their column name.
259
+
260
+
261
+ The first way to do this is to set the Database property `results_as_hash`
262
+ to true. If you do this, then all rows will be returned as Hash objects,
263
+ with the column names as the keys. (In this case, the `fields` property
264
+ is unavailable on the row, although the "types" property remains.)
265
+
266
+
267
+ ```ruby
268
+ db.results_as_hash = true
269
+ db.execute( "select * from table" ) do |row|
270
+ p row['column1']
271
+ p row['column2']
272
+ end
273
+ ```
274
+
275
+
276
+ A more granular way to do this is via `ResultSet#next_hash` or
277
+ `ResultSet#each_hash`.
278
+
279
+
280
+ ```ruby
281
+ results = db.query( "select * from table" )
282
+ row = results.next_hash
283
+ p row['column1']
284
+ ```
285
+
286
+
287
+ Another way is to use Ara Howard's
288
+ [`ArrayFields`](http://rubyforge.org/projects/arrayfields)
289
+ module. Just `require "arrayfields"`, and all of your rows will be indexable
290
+ by column name, even though they are still arrays!
291
+
292
+
293
+ ```ruby
294
+ require 'arrayfields'
295
+
296
+ ...
297
+ db.execute( "select * from table" ) do |row|
298
+ p row[0] == row['column1']
299
+ p row[1] == row['column2']
300
+ end
301
+ ```
302
+
303
+ ## How do I insert binary data into the database?
304
+
305
+ Use blobs. Blobs are new features of SQLite3. You have to use bind
306
+ variables to make it work:
307
+
308
+
309
+ ```ruby
310
+ db.execute( "insert into foo ( ?, ? )",
311
+ SQLite3::Blob.new( "\0\1\2\3\4\5" ),
312
+ SQLite3::Blob.new( "a\0b\0c\0d ) )
313
+ ```
314
+
315
+
316
+ The blob values must be indicated explicitly by binding each parameter to
317
+ a value of type `SQLite3::Blob`.
318
+
319
+ ## How do I do a DDL (insert, update, delete) statement?
320
+
321
+ You can actually do inserts, updates, and deletes in exactly the same way
322
+ as selects, but in general the `Database#execute` method will be most
323
+ convenient:
324
+
325
+
326
+ ```ruby
327
+ db.execute( "insert into table values ( ?, ? )", *bind_vars )
328
+ ```
329
+
330
+ ## How do I execute multiple statements in a single string?
331
+
332
+ The standard query methods (`Database#execute`, `Database#execute2`,
333
+ `Database#query`, and `Statement#execute`) will only execute the first
334
+ statement in the string that is given to them. Thus, if you have a
335
+ string with multiple SQL statements, each separated by a string,
336
+ you can't use those methods to execute them all at once.
337
+
338
+
339
+ Instead, use `Database#execute_batch`:
340
+
341
+
342
+ ```ruby
343
+ sql = <<SQL
344
+ create table the_table (
345
+ a varchar2(30),
346
+ b varchar2(30)
347
+ );
348
+
349
+ insert into the_table values ( 'one', 'two' );
350
+ insert into the_table values ( 'three', 'four' );
351
+ insert into the_table values ( 'five', 'six' );
352
+ SQL
353
+
354
+ db.execute_batch( sql )
355
+ ```
356
+
357
+
358
+ Unlike the other query methods, `Database#execute_batch` accepts no
359
+ block. It will also only ever return `nil`. Thus, it is really only
360
+ suitable for batch processing of DDL statements.
361
+
362
+ ## How do I begin/end a transaction
363
+
364
+ Use `Database#transaction` to start a transaction. If you give it a block,
365
+ the block will be automatically committed at the end of the block,
366
+ unless an exception was raised, in which case the transaction will be
367
+ rolled back. (Never explicitly call `Database#commit` or `Database#rollback`
368
+ inside of a transaction block--you'll get errors when the block
369
+ terminates!)
370
+
371
+
372
+ ```ruby
373
+ database.transaction do |db|
374
+ db.execute( "insert into table values ( 'a', 'b', 'c' )" )
375
+ ...
376
+ end
377
+ ```
378
+
379
+
380
+ Alternatively, if you don't give a block to `Database#transaction`, the
381
+ transaction remains open until you explicitly call `Database#commit` or
382
+ `Database#rollback`.
383
+
384
+
385
+ ```ruby
386
+ db.transaction
387
+ db.execute( "insert into table values ( 'a', 'b', 'c' )" )
388
+ db.commit
389
+ ```
390
+
391
+
392
+ Note that SQLite does not allow nested transactions, so you'll get errors
393
+ if you try to open a new transaction while one is already active. Use
394
+ `Database#transaction_active?` to determine whether a transaction is
395
+ active or not.
396
+
397
+ ## How do I discover metadata about a table/index?
398
+
399
+ ## How do I do tweak database settings?