Some basic N1QL questions, bucket case sensitive ,

I’ve some basic questions about N1QL.

  1. The bucket name is case sensitive.

cbq> select deptno,loc,dname from hr where type=‘dept2’ limit 1;
–> “msg”: “Keyspace not found keyspace hr - cause: No bucket named hr”

And select deptno,loc,dname from HR, work fine.

The bucket was created in Uppercase.
Any way to avoid this sensitive?

  1. The caracters used in a where must be enclose using single quota o double quota.
    select deptno,loc,dname from HR where type=‘dept2’ limit 1;
    generate a request id:
    “requestID”: “a2fe51cd-9a63-44a3-b0e5-624b29257dd5”,

select deptno,loc,dname from HR where type**=“dept2”** limit 1;
Generate another request ID.
“requestID”: “f52b37b4-51c8-4368-b18d-6558ded200fb”,
Any implication to use single o doublé quota?

  1. How can I display other metrics at N1QL level like: sortCount, mutationCount, errorCount , etc?

  2. When you use attributes alias like, select deptno as XXXX, ename as Nombre , the attributes order output Is ordered alphabetically and the write order is changed.
    Is posible to avoid this behavior?

Many Thanks

Hi Arturo,
quick answers

  1. yes all identifiers are case sensitive and there’s no way to avoid the behaviour.
    This is to avoid conflicts: you can have buckets multiple buckets named “hr” but with different combinations of casing (e.g. “Hr” and “hr”). If N1QL ignored casing it wouldn’t be able to differentiate between the two buckets above.
    Same argument goes for JSON field names.

  2. single and double quotes are mostly interchangeable. Double quoting allows some escaping that single quoting does not.

  3. if you are interested in obtaining metrics at the N1QL level, starting from 4.5 we have a couple of system keyspaces that list current and past requests: system:active_requests and system:completed_requests.

If you select from either of them you can access the metrics above for request that are running or requests that have completed.

Projection list field sorting cannot be turned off - it’s there because since N1QL uses flexible schema, it is much easier to see if fields are missing in individual result documents if the fields are sorted alphabetically.


1 Like

Also note that fields can be accessed case-insensistively, using back ticks and the letter i.

WHERE hr.`TYPE`i = …

Hi Marco,
Thanks for your answers this help me!


1 Like

Thanks Gerald for the additional help.


1 Like