oscerd opened a new pull request, #3009:
URL: https://github.com/apache/camel-kamelets/pull/3009
Fixing a defect I introduced in #3007.
The `statement` example shipped there does not work:
```yaml
example: "SELECT * FROM `travel-sample` LIMIT 10"
```
and it fails in the worst possible way — the source polls happily, logs
nothing alarming, and emits **no exchanges at all**.
## Two requirements, neither obvious
Both found by running the Kamelet against a live Couchbase while writing the
integration test in #3008.
**1. The document id must be aliased as `__id`.** `CouchbaseConsumer` does:
```java
String id = row.getString(SQL_DOCUMENT_ID_ALIAS); // "__id"
if (id == null) {
LOG.warn("Row does not contain '{}' field. ... Skipping row.", ...);
continue;
}
```
A query without `META().id AS __id` has every row skipped — at WARN level,
so a route looks healthy and simply never fires.
**2. The keyspace is the collection, not the bucket.** The consumer runs the
query through `scope.query(...)`, so `FROM <bucket>` resolves to
`<bucket>._default.<bucket>`:
```
Keyspace not found in CB datastore: default:mybucket._default.mybucket
```
The collection — normally `_default` — is what belongs there.
## The change
```diff
- description: The N1QL query to run against the bucket on each poll.
Used unless useView is true.
+ description: >-
+ The N1QL query to run against the bucket on each poll. Used
unless useView is true.
+ The query runs in the bucket scope, so the keyspace is the
collection - use _default
+ for the default collection rather than the bucket name. It must
also alias the document
+ id as __id, because rows without that field are skipped.
- example: "SELECT * FROM `travel-sample` LIMIT 10"
+ example: "SELECT META().id AS __id, * FROM _default"
```
Description only — no template or behavioural change. The example now
matches exactly what the integration test in #3008 uses and is proven to work
against a real cluster.
Kept separate from #3008 deliberately: that PR adds a test, this one
corrects a Kamelet, and they are reviewable independently even though the same
investigation produced both.
`script/validator` reports no errors and `mvn clean install` passes with
tests from the repository root.
---
_Claude Code on behalf of Andrea Cosentino_
--
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]