Forums (Obsolete)

Member

avir-waves - 2/20/2013 8:29:08 AM

REST GET - cannot query records by fields value

Hi,

We are using REST with kentico but failing to get a specific object records by passing a value such as:
http://devServer/rest/cms.user?where=FirstName='abc'
The REST site settings seems ok as we can get records by ID, and update a record as well with PUT, but not sure how to query a record by other fields value such as email/first/last name (for example).

Using fiddler we get the error - 'The remote server returned an error: (400) Bad Request.::: None'

Please help,
Avir


Certified Developer 8	Petr Dvorak - 2/20/2013 3:41:11 PM RE:REST GET - cannot query records by fields value Hi Avir, encoding the URL parameter does not help? http://devServer/rest/cms.user?where=FirstName%3D%27abc%27


Member	avir-waves - 2/21/2013 3:58:28 AM RE:REST GET - cannot query records by fields value No, we get a bad request message (error 400). But interestingly, when we run a REST request on the cms.country object using a where condition it works. But it is not working on the cms.user object. The same goes with TopN, LIKE and such.


Member	avir-waves - 2/26/2013 3:28:10 AM RE:REST GET - cannot query records by fields value OK. It looks like the solution is actually combined: 1. Use the 'all' as suggested. /rest/cms.user/all?where=UserIsEditor%3D1 2. Use encoded URL 3. User should have admin permissions to run a query on the cms.user object– (however, user with less permissions works ok on the countries object).

Kentico Support

kentico_zdenekc - 2/28/2013 8:56:18 AM

RE:REST GET - cannot query records by fields value

Hello all,

In a parallel discussion (direct support email conversation), we have found the cause of the issue.

The problem with non-functional /cms.user?where=... request is that without the /all parameter, the system preselects only the users from the current site (determined by the domain in the URL - matching a site domain name or domain alias). The former method internally used the SQL IN statement (with a set of IDs), which lead to query processor overload.
We should improve it in the next week hotfix release (7.0.24), the internal logic will use inner select, so this shouldn't be an issue anymore.

Thank you for your patience and understanding.
Regards,
Zdenek