New: Add Oracle implementation of UuidValue expression - #411
Conversation
Oracle stores a UUID as 16 raw bytes in a `raw(16)` column, so `prepareValue()` converts the canonical form with `DbUuidHelper::uuidToBlob()` and binds it as `DataType::LOB`. Requires yiisoft/db#1199.
4582eee to
113365c
Compare
CI showed PDO_OCI inserts NULL when the raw bytes are bound as a large object, so build the `HEXTORAW()` literal directly — the representation this driver already uses for binary values.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #411 +/- ##
=========================================
Coverage 97.82% 97.83%
- Complexity 250 251 +1
=========================================
Files 26 27 +1
Lines 828 831 +3
=========================================
+ Hits 810 813 +3
Misses 18 18 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
| public function build(ExpressionInterface $expression, array &$params = []): string | ||
| { | ||
| /** @var UuidValue $expression */ | ||
| return "HEXTORAW('" . str_replace('-', '', $expression->value) . "')"; |
There was a problem hiding this comment.
Will it work when $expression->value is 16 raw bytes? Needs a test
There was a problem hiding this comment.
$expression->value is always the canonical lowercase form — UuidValue::__construct() normalizes through DbUuidHelper::toUuid(), so 16 raw bytes are an input form rather than a state the builder can observe. That is what makes inlining the literal safe: stripping the dashes always leaves exactly 32 hexadecimal characters.
Both tests in UuidValueBuilderTest are now data-provider driven over every accepted form — canonical, canonical uppercase, 32 hex, 32 hex uppercase and 16 raw bytes. The build test asserts the same HEXTORAW('738146be87b149f2991336142fb6fcbe') for each, and testInsertAndSelectUuid() does a real-database round-trip per form. Green on Oracle 18 and 21 across PHP 8.1-8.5.
|
These The other workflows don't hit it because they install the core from the PR branch: It clears itself once #1199 is merged and 2.0.2 is tagged. If you'd rather see it green before that, adding |
Oracle half of
UuidValue, added in yiisoft/db#1199 — that PR has to be merged first.Oracle stores a UUID as 16 raw bytes (
ColumnDefinitionBuildermapsColumnType::UUIDtoraw(16)), soprepareValue()converts the canonical form withDbUuidHelper::uuidToBlob()and binds it asDataType::LOB.Draft, because I could not verify this locally —
pdo_ociis not available on my machine, so I am relying on CI for the round-trip test against a realraw(16)column. The SQLite and MySQL counterparts (yiisoft/db-sqlite#432, yiisoft/db-mysql#482) are verified locally.The open question is whether
bindValue($name, $bytes, PDO::PARAM_LOB)is right for araw(16)column under PDO_OCI, since this driver otherwise represents binary values as an inlineHEXTORAW('...')literal viaQueryBuilder::prepareBinary(). If CI shows the LOB parameter does not work, the alternative is to build the literal inbuild()instead:That needs no binding and is safe here because the value is already validated as a UUID, but it inlines the value rather than passing a parameter. Happy to take whichever you prefer.
The branch name matches the one in yiisoft/db#1199, so
install-packagesresolves the core package from it and CI runs against the new class.