Prevents something like `WHERE x = 5 AND x = 5` from becoming a two
component index key.
Closes#3656
Reviewed-by: Nikita Sivukhin (@sivukhin)
Closes#3658
## Purpose
- Deploy `tech.turso:turso:<version>` to maven central so that users can
easily use java bindings
- For example :
https://repo1.maven.org/maven2/io/github/seonwkim/turso/0.0.1/
## Requirements
- [x] Add the following github secrets.
- [x] MAVEN_CENTRAL_USERNAME
- [x] MAVEN_CENTRAL_PASSWORD
- [x] GPG_PRIVATE_KEY
- [x] GPG_PASSPHRASE
- [ ] Namespace `tech.turso` must be registered at maven central
- [ ] GPG key registration to key servers
- Notes
- Retrieve MAVEN_CENTRAL_USERNAME and MAVEN_CENTRAL_PASSWORD from
[maven central](https://central.sonatype.com/usertoken)
- GPG keys should be registered. You should distribute your keys to
designated(maven central supported) servers
- Refer to [GPG key related docs](https://central.sonatype.org/publ
ish/requirements/gpg/#distributing-your-public-key)
- Btw, I used `keyserver.ubuntu.com` key server while testing
### [Maven Central Username &
Password](https://central.sonatype.com/usertoken)
<img width="2878" height="1338" alt="image"
src="https://github.com/user-
attachments/assets/03e6f967-a7f6-46b8-aef5-d15772bd9eea" />
### [Maven Central
Namespace](https://central.sonatype.com/publishing/namespaces)
<img width="1424" height="456" alt="image" src="https://github.com/user-
attachments/assets/8c0f4f17-bf5a-4c6a-bc47-748d86cd1f1a" />
## Future Works
- Currently, we depend on gradle.properties to determine the version of
our dependency and it's cumbersome to always change the version
manually. Let's find a better solution.
Closes#3624
This PR introduces sparse vectors support and jaccard distance
implementation.
Also, this PR restructure the code to have all vector operations in
separate files (they grow pretty quickly as new vector representations
added to the DB).
Closes#3647
Various little fixes to `Sorter` that reduce unnecessary work.
Makes TPC-H query 1 roughly 2x faster, which is a lot because it
originally took 30-40 seconds depending on the CI run
Closes#3645
I found an application in the open that expects sqlite_version() to
return a specific string (higher than 3.8...).
We had tons of those issues at Scylla, and the lesson was that you tell
your kids not to lie, but when life hits, well... you lie.
We'll add a new function, turso_version, that tells the truth.
Closes#3635
- Removed a general clippy rule to allow all dead code and subsequently
removed a lot of dead code
- Fixed Column constraints in Sql Generation to accommodate all Column
constraints available to the Parser and print the constraints in other
sql queries.
- Moved Generation of simulator values to separate files
These are some of the changes I made in my Alter Table PR that I am
upstreaming here
Closes#3649
- On each interaction we assume that the value is NULL, so we need to
set it like so for every interaction in the list. So we force to not
emit this NULL as constant;
- Forces a copy so IN expressions works inside an aggregation
expression. Not ideal but it works, we should work more on the query
planner for sure.
I found an application in the open that expects sqlite_version() to
return a specific string (higher than 3.8...).
We had tons of those issues at Scylla, and the lesson was that you
tell your kids not to lie, but when life hits, well... you lie.
We'll add a new function, turso_version, that tells the truth.
- errors are hard to handle in case of some scan operations (something went wrong in the middle - whoe query aborted)
- it will be more flexibly if we will return NaN and let user handle situation
Made a new PR based on @sivukhin 's PR #2869 that had a lot of
conflicts. You can check out the PR description from there.
## The main idea is:
Before, if we had an index on `x` and had a query like `WHERE x > 100
and x < 200`, the plan would be something like:
```
- Seek to first row where x > 100
- Then, for every row, discard the row if x >= 200
```
This is highly wasteful in cases where there are a lot of rows where `x
>= 200`. Since our index is sorted on `x`, we know that once we hit the
_first_ row where `x >= 200`, we can stop iterating entirely.
So, the new plan is:
```
- Seek to first row where x > 100
- Then, iterate rows until x >= 200, and then stop
```
This also improves the situation for multi-column indexes. Imagine index
on `(x,y)` and a condition like `WHERE x = 100 and y > 100 and y < 200`.
Before, the plan was:
```
- Seek to first row where x=100 and y > 100
- Then, iterate rows while x = 100 and discard the row if y >= 200
- Stop when x > 100
```
This also suffers from a problem where if there are a lot of rows where
`x=100` and `y >= 200`, we go through those rows unnecessarily. The new
plan is:
```
- Seek to first row where x=100 and y > 100
- Then, iterate rows while x = 100 and y < 200
- Stop when either x > 100 or y >= 200
```
Which prevents us from iterating rows like `x=100, y = 666`
unnecessarily because we know the index is sorted on `(x,y)` - once we
hit any row where `x>100` OR `x=100, y >= 200`, we can stop.
Closes#3644
## Summary
Implemented Calendar-based Date/Time/Timestamp getter methods in
JDBC4ResultSet to support timezone conversions.
## Changes
- Implemented `getDate(int, Calendar)` and `getDate(String, Calendar)`
- Implemented `getTime(int, Calendar)` and `getTime(String, Calendar)`
- Implemented `getTimestamp(int, Calendar)` and `getTimestamp(String,
Calendar)`
- Fixed timezone conversion logic (changed from subtraction to addition)
- Added comprehensive test cases for all implemented methods
Test Results
- All tests passed successfully
- New tests validate timezone conversion with UTC and Seoul (UTC+9)
Reviewed-by: Kim Seon Woo (@seonWKim)
Closes#3607
Before, we just skipped evaluating `Id`, `Qualified` and
`DoublyQualified` if `referenced_tables` was `None`, leading to shit
like #3621. Let's eagerly return `"No such column"` parse errors in
these cases instead, and punch exceptions for cases where that doesn't
cleanly work
Top tip: use `Hide whitespace` toggle when inspecting the diff of this
PR
Closes#3621
Reviewed-by: Preston Thorpe <preston@turso.tech>
Closes#3626
