## Purpose
* Implement `setObject(int, Object)` to support binding of common Java
types to SQL parameters in JDBC4.
* This implementation currently covers only standard JDBC4 supported
types. LOB and stream bindings are not yet implemented.
## Changes
* Implemented JDBC4PreparedStatement#setObject(int, Object) handling for
* `String`, `Integer`, `Long`, `Boolean`, `Double`, `Float`, `Byte`,
`Short`
* `byte[]`, `Date`, `Time`, `Timestamp`, `BigDecimal`
* Added validation for unsupported types (`Blob`, `Clob`, `InputStream`,
`Reader`)
* Added corresponding unit test `testSetObjectCoversAllSupportedTypes`
to verify correctness
## Note
* Additional work (e.g., LOB/Stream handling) will be addressed
separately once driver support is available.
## Related Issue
#615
Reviewed-by: Kim Seon Woo (@seonWKim)
Closes#3864
Closes#3748
Right now if any error happens during an interactive tx that causes the
`Transaction` to drop, the program will panic.
To prevent this, we store the `DropBehavior` of the transaction on the
`Connection` when it drops and issue the corresponding action (ROLLBACK
/ COMMIT / IGNORE / PANIC) the next time `Connection` is used to access
the database. This defaults to `IGNORE`.
I don't know how good this solution is, but we can at least prevent a
panic by storing whether the connection has a dangling transaction and
roll it back automatically the next time the connection tries to do
something.
Reviewed-by: Preston Thorpe <preston@turso.tech>
Closes#3750
Rolling back a transaction on Error should result in
`connection.auto_commit` being set back to true.
Added a regression test for this where a UNIQUE constraint violation
rolls back the transaction and trying to COMMIT will fail.
Currently, our default conflict resolution strategy is ROLLBACK, which
ends the transaction. In SQLite, the default is ABORT, which rolls back
the current statement but allows the transaction to continue.
We should migrate to default ABORT once we support subtransactions.
Closes#3746
Reviewed-by: Preston Thorpe <preston@turso.tech>
Closes#3747
Closes#3748
Right now if any error happens during an interactive tx that causes the
`Transaction` to drop, the program will panic.
I don't know how good this solution is, but we can at least prevent a panic
by storing whether the connection has a dangling transaction and roll it back
automatically the next time the connection tries to do something.
## 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
## 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
