How can I run a N1QL query to return data with unicode notation inside correctly?

SQL++
1

I am running this N1QL query from Couchbase Server 6.0.3 :

SELECT “Redacci\u00f3n” where 1

Query Results:
[
{
“$1”: “Redacción”
}
]

How can I run this query to return exact data value ?

[
{
“$1”: “Redacci\u00f3n”
}
]

1 Like
2

That might be display internally it might be still unicode

3

Hi @vsr1

I have experienced a similar problem when migrating bucket keys to another with this query

INSERT INTO `newbucket` (KEY _k, VALUE _v)
SELECT META().id _k, _v from `oldbucket` _v
WHERE meta().id like "users::%"

In the oldbucket I have raw texts with this form: “Redacci\u00f3n”
But when you move it to the newbucket, it becomes “Redacción” :frowning:

This is a problem because the application that uses the data fails (i can’t change de app to be unicode ready)

I have only succeeded to migrate the data from one oldbucket to another newbucket (without raw converting it to unicode) using this cbtransfer

cbtransfer http://10.10.10.1:8091 http://10.10.10.2:8091 -b oldbucket -B newbucket -k '^users\:\:' -u user -p pass -t 8 -x batch_max_size=5000

but it’s ten times slower than N1QL

I would also like to know with what N1QL query can respect the raw texts without converting them to unicode in order to move them between buckets (it’s a process I have to do very often)
Thanks

4

At present N1QL process the JOSN object and there is no way tell it is raw string.
use primary index and get the document keys and Use SDK get the documents and insert into different bucket.

If you need to transfer on different cluster you can use XDCR https://docs.couchbase.com/server/current/manage/manage-xdcr/xdcr-management-overview.html.

Also you can use cbtransfer with -t option

-t THREADS, --threads=THREADS
Number of concurrent workers threads performing the
transfer

5

It is a pity that N1QL silently processes JSON, and no flag can be set to use the data in raw mode without altering its content.
It’s a pity because my old application only uses the data service (key-value) and altering the data causes the encoding to fail :frowning:

I will keep trying a more efficient way to do these migrations with cbtransfer

Thank you for clarifying this limitation