rishi-rana commented on PR #39773: URL: https://github.com/apache/shardingsphere/pull/39773#issuecomment-5685124366
Fixed in 2571d21. `FirebirdOpenBlobCommandExecutor` now resolves content by id instead of only consulting the result BLOB store: - zero — NULL BLOB quad, opens an empty BLOB (unchanged); - negative — result BLOB store, rejected when the content is missing (unchanged); - positive — `FirebirdBlobWriteCache`, returning the stored content of a created BLOB, rejected when the id is unknown or still open. `isClosed()` returns false for both an unknown id and an open one, so a single check covers the "reject unknown or unclosed" requirement, and the content is then read through `getBlobData()` — the same pair `bindBlobParameters()` already uses, so no new cache API was needed. On the test: my first attempt set up the write cache directly rather than running the commands, which would not have covered what you asked. A real `close_blob` also calls `FirebirdBlobReadCache.removeBlob()` and `FirebirdBlobHandleGenerator.releaseBlobHandle()`, so the handle is freed and reused by the following `open_blob`, and the id comes from `FirebirdBlobIdGenerator` rather than being hardcoded. `assertExecuteAfterCreatedBlobIsClosed` now drives `FirebirdCreateBlobCommandExecutor` -> `FirebirdPutBlobSegmentCommandExecutor` -> `FirebirdCloseBlobCommandExecutor` -> `FirebirdOpenBlobCommandExecutor` and asserts the stored bytes are returned through `readSegment()`. Against the previous implementation it fails with `InvalidSegstrIdException: Invalid BLOB id: 1`, reproducing the reported behaviour. Also added `assertExecuteWhenCreatedBlobIsNotClosed` (same create and put sequence, no close) and `assertExecuteWithUnknownResultBlobId` for the negative-id branch, which had no direct coverage. Verification on this head: 32 tests in `database/exception/dialect/firebird` and 282 in `proxy/frontend/dialect/firebird`, zero failures; `spotless:check checkstyle:check -Pcheck` clean for both modules. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
