[ 
https://issues.apache.org/jira/browse/CAMEL-26020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18130973#comment-18130973
 ] 

Claus Ibsen commented on CAMEL-26020:
-------------------------------------

Fix in https://github.com/apache/camel/pull/28359

_Claude Code on behalf of davsclaus_

> 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
>            Assignee: Claus Ibsen
>            Priority: Major
>             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)

Reply via email to