SQLite Version 3.35.0 - Beta 1
We have reached "pencils down" for the SQLite 3.35 development cycle. Our goal is no further changes other than minor code formatting, or documentation, or bug fixes.
A new prerelease snapshot is available. Call this snapshot 3.35.0-beta-1. Please download and test. Report any problems or concerns to this forum, or via private email to drh at sqlite dot org.
See the change log for a summary of the many enhancements in the 3.35 release.
The target release date is 2021-03-30, though that date might be moved sooner or later depending on how things go over the next week. A release checklist for version 3.35.0 is on-line. The release will happen when that checklist goes all green. As I type this, the checklist is all white - indicating that nothing has been checked off yet. Green probably won't start appearing until one week prior to the anticipated release.
Green has begun to appear on the SQLite 3.35.0 release checklist. If all goes well, the checklist will turn completely green over the next few days, after which the release will occur. So this might be your last opportunity to comment or complain about any of the enhancements, changes, and new features in the 3.35.0 release.
The documentation of trunc(X) seems to be wrong. If trunc(X) rounds towards zero then trunc(-3.5) should return -3. But -3 is larger than -3.5 (contradiction to the first sentence).
(4.1) By Larry Brasfield (larrybr) on 2021-03-09 23:02:27 edited from 4.0 in reply to 3 [link] [source]
In mathematics, the terms "greater than" and "less than" refer to relative positions on the "number line", with more negative numbers considered to be "less than" more positive numbers, and more positive numbers considered to be "greater than" more negative numbers.
The term "larger" is different, referring to relative magnitude or distance from zero in either direction (toward -Infinity or +Infinity.) For example, if somebody said they had a large discrepancy in their tax return, they might be referring to some entry that was either much more negative or much more positive than it should be.
The terms "larger" and "smaller" should not be confused with "greater than" and "less than". They seem to mean the same thing in colloquial use, speaking about positive values, such as height or weight. When speaking about negative values, the former terms can be ambiguous. The term "magnitude" might be better, but has much lower usage. (about 1/5x) So it would be worse for some.
can you please supply the return code(s) which will be returned if the statement fails for those reasons ?
The return code is always the same: SQLITE_ERROR.
(7) By Dan Shearer (danshearer) on 2021-03-10 15:53:23 in reply to 1 [source]
Richard Hipp (drh) wrote on 2021-03-01 16:54:
... minor code formatting, or documentation ...
Can I merge this into trunk: https://sqlite.org/src/file?name=src/btree.h&ci=btree-code-documentation ?
(there has been just one change since then, the addition of "#define BTREE_PREFORMAT").
(8) By Dan Shearer (danshearer) on 2021-03-10 15:56:03 in reply to 7 [link] [source]
With what I know now the comments in btree.h should probably say "MVCC-like" or "MVCC-style". I'm not sure that BTree was intended to be strictly MVCC, just to be a pragmatic solution that can deliver isolation, right?
MVCC is implemented on the documents, each key or iterator is checked for MVCC visibility during a scan/enumeration. A temporary Document can also be created from an index key entry (not implemented yet.) Each document version has a vector of the keys created for that version. This vector Each index entry has an arbitrary user created schema that is provided along with the index key.
So, to answer you directly, MVCC is either directly supported, or not, as designated by the table attributes.
BTREE keys only/MVCC.
- obtain a timestamp and append those binary bytes (big Endian) to each of the user's keys
- open a cursor and begin a scan of the btree keys at the desired start point.
- each key delivered by the cursor will be checked for visibility. (MVCC)
BTree Keys generated automatically on UPSERT.
- append the rowId to the user's key to find the timestamp.
- As the document version's keys compare each of the key values from the previous version vector of the document against the new version's keys and insert/replace/remove those keys visible under the timestamp. (MVCC)
Note: both of these flavors permit lazy removes of the Btree's keys, or batching.