Lines Matching refs:R
51 # EVIDENCE-OF: R-15060-13876 A 1-dimensional R*Tree thus has 3 columns.
55 # EVIDENCE-OF: R-19353-19546 A 2-dimensional R*Tree has 5 columns.
59 # EVIDENCE-OF: R-13615-19528 A 3-dimensional R*Tree has 7 columns.
65 # EVIDENCE-OF: R-53479-41922 A 4-dimensional R*Tree has 9 columns.
71 # EVIDENCE-OF: R-13981-28768 And a 5-dimensional R*Tree has 11 columns.
80 # EVIDENCE-OF: R-61533-25862 The SQLite R*Tree implementation does not
81 # support R*Trees wider than 5 dimensions.
96 # EVIDENCE-OF: R-16717-50504 Each R*Tree index is a virtual table with
113 # EVIDENCE-OF: R-17874-21123 The first column of an SQLite R*Tree is
116 # EVIDENCE-OF: R-46619-65417 The first column is always a 64-bit signed
119 # EVIDENCE-OF: R-46866-24036 It may only store a 64-bit signed integer
122 # EVIDENCE-OF: R-00250-64843 If an attempt is made to insert any other
149 # EVIDENCE-OF: R-15544-29079 Inserting a NULL value into this column
170 # EVIDENCE-OF: R-64317-38978 The other columns are pairs, one pair per
203 # EVIDENCE-OF: R-08054-15429 The min/max-value pair columns are stored
230 # EVIDENCE-OF: R-47371-54529 Unlike regular SQLite tables which can
231 # store data in a variety of datatypes and formats, the R*Tree rigidly
234 # EVIDENCE-OF: R-39153-14977 If any other type of value is inserted into
283 # EVIDENCE-OF: R-15142-18077 A new R*Tree index is created as follows:
289 # EVIDENCE-OF: R-51698-09302 The <name> is the name your
290 # application chooses for the R*Tree index and <column-names> is a
294 # EVIDENCE-OF: R-50130-53472 The virtual <name> table creates
300 # EVIDENCE-OF: R-45256-35998 The names of these shadow tables are:
309 # EVIDENCE-OF: R-11241-54478 As an example, consider creating a
310 # two-dimensional R*Tree index for use in spatial queries: CREATE
324 # EVIDENCE-OF: R-02287-33529 The shadow tables are ordinary SQLite data
339 # EVIDENCE-OF: R-10863-13089 You can query them directly if you like,
349 # EVIDENCE-OF: R-05650-46070 And you can UPDATE, DELETE, INSERT or even
350 # DROP the shadow tables, though doing so will corrupt your R*Tree
372 # EVIDENCE-OF: R-44253-50720 In the argments to "rtree" in the CREATE
385 # EVIDENCE-OF: R-52032-06717 This means, for example, that if you try to
408 # EVIDENCE-OF: R-06893-30579 In an RTREE virtual table, the first column
421 # EVIDENCE-OF: R-06224-52418 In an RTREE_I32 virtual table, all columns
446 # EVIDENCE-OF: R-36195-31555 The usual INSERT, UPDATE, and DELETE
447 # commands work on an R*Tree index just like on regular tables.
475 # EVIDENCE-OF: R-56987-45305
530 # EVIDENCE-OF: R-45880-07724 Any valid query will work against an R*Tree
546 # EVIDENCE-OF: R-60814-18273 The R*Tree implementation just makes some
553 # EVIDENCE-OF: R-37800-50174 Queries against the primary key are
557 # EVIDENCE-OF: R-35847-18866 The big reason for using an R*Tree is so
561 # EVIDENCE-OF: R-49927-54202
568 # EVIDENCE-OF: R-12823-37176 The query above will quickly locate all
570 # even if the R*Tree contains many entries.
580 # EVIDENCE-OF: R-07351-00257 For example, to find all zipcode bounding
587 # EVIDENCE-OF: R-39094-01937 This second query will find both 28269
611 # EVIDENCE-OF: R-02723-34107 Note that it is not necessary for all
612 # coordinates in an R*Tree index to be constrained in order for the
615 # EVIDENCE-OF: R-22490-27246 One might, for example, want to query all
636 # EVIDENCE-OF: R-08327-00674 By default, coordinates are stored in an
637 # R*Tree using 32-bit floating point values.
639 # EVIDENCE-OF: R-22000-53613 The default virtual table ("rtree") stores
652 # EVIDENCE-OF: R-39127-51288 When a coordinate cannot be exactly
680 # EVIDENCE-OF: R-45870-62834 Thus, bounding boxes might be slightly
701 # EVIDENCE-OF: R-55979-39402 It is the nature of the Guttman R-Tree
730 # EVIDENCE-OF: R-00683-48865 For this reason, it is not generally
731 # possible to modify the R-Tree in the middle of a query of the R-Tree.
753 # EVIDENCE-OF: R-19740-29710 So, for example, suppose an application
754 # runs one query against an R-Tree like this: SELECT id FROM demo_index
760 # EVIDENCE-OF: R-52919-32711 Then the UPDATE might fail with an
785 # EVIDENCE-OF: R-32604-49843 Ordinary tables in SQLite are able to read
818 # EVIDENCE-OF: R-06177-00576 And R-Tree can appear to read and write at
846 # EVIDENCE-OF: R-21062-30088 For the example above, one might create an
907 # EVIDENCE-OF: R-32671-43888 Then an efficient way to find the specific
922 # EVIDENCE-OF: R-32761-23915 One would get the same answer without the
923 # use of the R*Tree index using the following simpler query: SELECT
932 # EVIDENCE-OF: R-40261-32799 The problem with this latter query is that
941 # EVIDENCE-OF: R-24212-52761 The use of the R*Tree in the penultimate
947 # EVIDENCE-OF: R-39057-63901 The R*Tree index did not find the exact
964 # EVIDENCE-OF: R-46566-43213 Beginning with SQLite version 3.24.0
969 # EVIDENCE-OF: R-41287-48160 Auxiliary columns are marked with a "+"
995 # EVIDENCE-OF: R-30514-26093 Auxiliary columns must come after all of
1010 # EVIDENCE-OF: R-01280-03635 An RTREE table can have no more than 100
1073 # EVIDENCE-OF: R-05552-15084
1102 catch { array unset R }
1103 db eval {SELECT * FROM demo_index2} R { set r1 [array names R] }
1104 catch { array unset R }
1105 db eval {SELECT * FROM demo_index NATURAL JOIN demo_data } R {
1106 set r2 [array names R]
1111 # EVIDENCE-OF: R-26099-32169 SELECT objname FROM demo_index2 WHERE
1166 # EVIDENCE-OF: R-24021-02490 For auxiliary columns, only the name of the
1169 # EVIDENCE-OF: R-39906-44154 Constraints such as NOT NULL, UNIQUE,
1218 # EVIDENCE-OF: R-21011-43790 If integer coordinates are desired, declare
1227 # EVIDENCE-OF: R-09193-49806 An rtree_i32 stores coordinates as 32-bit
1318 # EVIDENCE-OF: R-33789-46762 The content of an R*Tree index is actually
1320 # name of the R*Tree.
1322 # EVIDENCE-OF: R-39849-06566 This is their schema: CREATE TABLE
1327 # EVIDENCE-OF: R-07489-10051 The "%" in the name of each shadow table is
1328 # replaced by the name of the R*Tree virtual table. So, if the name of
1329 # the R*Tree table is "xyz" then the three shadow tables would be
1343 # EVIDENCE-OF: R-51070-59303 There is one entry in the %_node table for
1344 # each R*Tree node.
1359 # EVIDENCE-OF: R-27261-09153 All nodes other than the root have an entry
1368 # EVIDENCE-OF: R-02358-35037 The %_rowid shadow table maps entry rowids
1390 # EVIDENCE-OF: R-65201-22208 Extra columns appended to the %_rowid table
1393 # EVIDENCE-OF: R-44161-28345 The names of these extra %_rowid columns
1427 # EVIDENCE-OF: R-13571-45795 The scalar SQL function rtreecheck(R) or
1428 # rtreecheck(S,R) runs an integrity check on the rtree table named R
1431 # EVIDENCE-OF: R-36011-59963 The function returns a human-language
1468 # EVIDENCE-OF: R-45759-33459 Example: To verify that an R*Tree named
1490 # EVIDENCE-OF: R-02555-31045 for each dimension, (coord1 <= coord2).
1508 # EVIDENCE-OF: R-13844-15873 unless the cell is on the root node, that
1525 # EVIDENCE-OF: R-02505-03621 for leaf nodes, that there is an entry in
1538 # EVIDENCE-OF: R-50927-02218 for cells on non-leaf nodes, that there is
1559 # EVIDENCE-OF: R-23235-09153 That there are the same number of entries
1570 # EVIDENCE-OF: R-62800-43436 That there are the same number of entries