Claus Ibsen created CAMEL-26020:
-----------------------------------
Summary: camel-couchbase - the document id falls back to the
endpoint id, unknown operations do nothing, and the generated SQL++ query fails
without a collection
Key: CAMEL-26020
URL: https://issues.apache.org/jira/browse/CAMEL-26020
Project: Camel
Issue Type: Bug
Components: camel-couchbase
Affects Versions: 4.18.0, 4.22.0, 4.23.0
Reporter: Claus Ibsen
Fix For: 4.24.0
Found while checking the body types of the couchbase component for the catalog
(CAMEL-24961). The checks ran against {{docker.io/couchbase/server:8.0.3}} set
with {{-Dcouchbase.container}}: the {{mirror.gcr.io}} image that {{camel infra
run couchbase}} uses runs only as amd64, and on an arm64 Mac it times out
waiting for {{/pools}} under emulation.
h4. 1. Without the CamelCouchbaseId header the document id is the Camel
endpoint id, and the key option is never read
Without the {{CamelCouchbaseId}} header, the producer takes the document id
from {{endpoint.getId()}} ({{CouchbaseProducer}}, main 07d2e7a987bc, line 138),
which is the id Camel gives the endpoint, such as "endpoint6", and not the
{{key}} option: nothing reads that option. So the check "CamelCouchbaseId is
not specified in message header or endpoint URL" (line 146) never fails, and
every document without the header is written under the same made-up id.
The producer also removes {{CamelCouchbaseId}} after each call (line 166), so a
CCB_GET after a CCB_PUT in the same route reads the endpoint id and fails with
{{DocumentNotFoundException}}.
Checked on 4.24.0-SNAPSHOT with {{camel run}} against Couchbase 8.0.3: a PUT
with no header stored "No id" under the id {{endpoint6}}, and a PUT with
{{key=from-option}} stored "Key option" under {{endpoint25}}.
*Proposed change*: use the {{key}} option when the header is not set, and fail
when neither gives an id.
h4. 2. An unknown operation does nothing: add the operation values as an enum
The {{operation}} option is a free String, compared with {{equals}} to CCB_PUT,
CCB_GET and CCB_DEL ({{CouchbaseProducer}}, main 07d2e7a987bc, lines 149-159).
Any other value, such as a misspelled one or {{ccb_get}}, does nothing: no
error, the body stays as it was, and the id header is still removed. The
catalog does not know the values either, so tooling cannot check them or say
what the body is after each operation.
Checked on 4.24.0-SNAPSHOT with {{camel run}}: {{operation=NOSUCH}} left the
body "other", with no error.
*Proposed change*: add {{enums = "CCB_PUT,CCB_GET,CCB_DEL"}} to the
{{@UriParam}} of {{operation}} ({{CouchbaseEndpoint}}, line 113), so the
catalog lists the values, and fail on a value that is not one of them. The
catalog body types of the producer (CAMEL-24961) can then say the body per
operation: {{true}} for CCB_PUT, the {{GetResult}} for CCB_GET and the text of
the {{MutationResult}} for CCB_DEL.
h4. 3. Without the collection option the generated SQL++ query fails on every
poll
When neither {{statement}} nor {{collection}} is set, the consumer generates
{{SELECT META().id AS __id, * FROM `<bucket>`}}
({{CouchbaseEndpoint.buildSqlQuery}}, main 07d2e7a987bc, line 475) and runs it
on the scope ({{scope.query}}, {{CouchbaseConsumer}}, line 177). In a scope,
Couchbase reads the bucket name as a collection of that scope, so every poll
fails with {{IndexFailureException}}: "Keyspace not found in CB datastore:
default:survey._default.survey". The explicit statements of the docs, such as
{{FROM `myBucket`}}, fail the same way. This is the code of CAMEL-23218, since
4.19.0.
Checked on 4.24.0-SNAPSHOT with {{camel run}} against Couchbase 8.0.3, with a
bucket {{survey}} and a primary index on it:
* {{couchbase:http://localhost:8091?bucket=survey&...&limit=2}}, also with the
{{connectionString}} that ConsumeSqlQueryIT uses: "Keyspace not found" on every
poll;
* the same with {{collection=_default}}: one exchange per document.
*Proposed change*: use the collection, or {{_default}}, as the keyspace of the
generated statement when the query runs on the scope, and fix the statements in
the docs.
h4. 4. JSON text is stored as a JSON string, and bytes or a stream fail
CCB_PUT gives the body to {{collection.upsert}} as it is
({{CouchbaseCollectionOperation}}, main 07d2e7a987bc, line 63), and the SDK
writes it with its JSON transcoder. So JSON text is stored as a JSON string:
the document holds {{"{\"id\":\"j1\"}"}} and not the object. A byte array fails
with "byte[] input is not supported for the JsonTranscoder!", and a stream
fails with "Serializing of content ... to JSON failed". Only a Map, a List or a
POJO is stored as a JSON document.
Checked on 4.24.0-SNAPSHOT with {{camel run}} against Couchbase 8.0.3: a PUT of
{{{"id":"j1","name":"Camel"}}} as text gave
{{GetResult{content="{\"id\":\"j1\",\"name\":\"Camel\"}"}}} on CCB_GET.
*Proposed change*: store text and bytes that hold JSON with the
{{RawJsonTranscoder}}, or turn JSON text into a {{JsonObject}} first, and say
in the docs how each body is stored.
h4. Also read in the code, not run
* In view mode, {{row.id().get()}} fails for the rows of a reduce view, and
{{keyAs(String.class)}} for a compound key ({{CouchbaseConsumer}}, lines 248
and 264); either stops the whole poll.
* ConsumeMessagesWithLimitIT and ConsumeResumeStrategyIT set
{{designDocumentName}} and {{viewName}} without {{useView=true}}, so since
CAMEL-23218 they run SQL++ queries.
_Claude Code on behalf of davsclaus_
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
