Named parameter has no value, even when passing one

What i’m trying to do is to query the bucket ‘default’ with this query “SELECT META().id, file FROM default WHERE META().id LIKE ‘file_’|| $name ||’%”

In python the line looks like res = bucket.query(“SELECT META().id, file FROM default WHERE META().id LIKE ‘file_’|| $name ||’%’”, name=“128794”) (currently passing a hard coded value to comfirm the bug, it’s still there).

This should work as to my understanding, but it’s throwing an exception with the error msg “Error evaluating filter. - cause: No value for named parameter $name”

Best regards,

@Magnus you have mentioned $name in your query. Python SDK treats it as a named parameter that needs to be passed, which you are missing.

something along this
query = N1QLQuery(

I’m passing it with the ", name=“128794”.

Which Python SDK version are you using ? and can you paste your code snippet as to how you connect to the server and execute the query please ?

SDK Version is 3.0.0

I import Bucket from couchbase.bucket, and connect via self.bucket = Bucket(“couchbase://our_hosts/default”, password=“ThePassword”, username=“theUsername” ).

The the query is made in self.bucket.query(“QueryString”, name=“128794”).

It works when i just hard code a name, but i’m gonna need to be able to select the name in production.

Best regards,

The 3.0 sdk expects you to issue queries from the cluster object rather than the bucket. However, since the bucket, collection and cluster share a base class (which has a query function in it), that leaks out and could be used. The sdk3 n1ql docs have some examples of how to make queries now. But, basically you do cluster.query(query_string, name=“128794”) and you are all set.

I should say we plan to tighten up that leaking implementation – it is super confusing. Especially this one, as it is how you made a query in 2.x (off the bucket).

1 Like

Alright, used to just query the cluster, but as my auth kept failing I thought i’d give this a try. I’ll be going back to trying to fix up the cluster, Thanks alot!


cool! Glad that helped!

Agreed on tightening up exposed functions - I was already working on some refactoring so vestigial functionality is removed/hidden, and not just in the API docs. Hopefully will get this in to the codebase soon.