mirror of
https://github.com/tursodatabase/limbo.git
synced 2025-12-23 08:21:09 +00:00
097510216e
My goal with this patch is to be able to implement the ProjectOperator for DBSP circuits using VDBE for expression evaluation. *not* doing so is dangerous for the following reason: we will end up with different, subtle, and incompatible behavior between SQLite expressions if they are used in views versus outside of views. In fact, even in our prototype had them: our projection tests, which used to pass, were actually wrong =) (sqlite would return something different if those functions were executed outside the view context) For optimization reasons, we single out trivial expressions: they don't have go through VDBE. Trivial expressions are expressions that only involve Columns, Literals, and simple operators on elements of the same type. Even type coercion takes this out of the realm of trivial. Everything that is not trivial, is then translated with translate_expr - in the same way SQLite will, and then compiled with VDBE. We can, over time, make this process much better. There are essentially infinite opportunities for optimization here. But for now, the main warts are: * VDBE execution needs a connection * There is no good way in VDBE to pass parameters to a program. * It is almost trivial to pollute the original connection. For example, we need to issue HALT for the program to stop, but seeing that halt will usually cause the program to try and halt the original program. Subprograms, like the ones we use in triggers are a possible solution, but they are much more expensive to execute, especially given that our execution would essentially have to have a program with no other role than to wrap the subprogram. Therefore, what I am doing is: * There is an in-memory database inside the projection operator (an obvious optimization is to share it with *all* projection operators). * We obtain a connection to that database when the operator is created * We use that connection to execute our VDBE, which offers a clean, safe and isolated way to execute the expression. * We feed the values to the program manually by editing the registers directly. |
||
|---|---|---|
| .. | ||
| cli_tests | ||
| javascript | ||
| sqlite3 | ||
| sqlite_test_ext | ||
| test_files | ||
| unreliable-libc | ||
| wal | ||
| agg-functions.test | ||
| all.test | ||
| alter_table.test | ||
| analyze.test | ||
| attach.test | ||
| boolean.test | ||
| changes.test | ||
| cmdlineshell.test | ||
| coalesce.test | ||
| collate.test | ||
| compare.test | ||
| concat.test | ||
| create_table.test | ||
| default_value.test | ||
| delete.test | ||
| drop_index.test | ||
| drop_table.test | ||
| gen-database.py | ||
| glob.test | ||
| groupby.test | ||
| insert.test | ||
| integrity_check.test | ||
| join.test | ||
| json.test | ||
| like.test | ||
| literal.test | ||
| materialized_views.test | ||
| math.test | ||
| null.test | ||
| offset.test | ||
| orderby.test | ||
| pragma.test | ||
| pyproject.toml | ||
| README.md | ||
| rollback.test | ||
| scalar-functions-datetime.test | ||
| scalar-functions-printf.test | ||
| scalar-functions.test | ||
| select.test | ||
| subquery.test | ||
| tester.tcl | ||
| testing.db | ||
| testing_norowidalias.db | ||
| testing_small.db | ||
| testing_user_version_10.db | ||
| time.test | ||
| total-changes.test | ||
| transactions.test | ||
| update.test | ||
| values.test | ||
| vector.test | ||
| views.test | ||
| vtab.test | ||
| where.test | ||
Turso Testing
Testing Extensions
When adding tests for extensions, please follow these guidelines:
- Tests that verify the internal logic or behavior of a particular extension should go into
cli_tests/extensions.py. - Tests that verify how extensions interact with the database engine, such as virtual table handling, should be written
in TCL (see
vtab.testas an example).
To check which extensions are available in TCL, or to add a new one, refer to the tester.tcl file and look at the extension_map.