Plone REST API - Filtering search results using a value inside an object

Plone Support
1

I am trying to use @search or @querystring-search endpoints to limit the response to include only items with priority.token = 1.

An item includes a priority object as follows:

"priority": {
    "title": "1 Important",
    "token": "1"
}

Using @search endpoint, I tried adding priority.token=1, but that resulted in this error:

"Query for index <FieldIndex at priority> is missing a 'query' key!"

So, is it possible to filter the results using a value inside an object? And how to do that?

2

This is not how searching and indexing in Plone works.
If you want to search for token, you need to create a FieldIndex token and a related indexer that would index the token attribute of priority objects. Same for title which would be a fulltext index.

1 Like
3

Try skipping the token, search for just fow what priority returns ( probably either 1 or '1 Importanr' )

4

That does not work either.

5

Show code

6

Not helpful....please provide information about your data model, implementation, catalog setup and your indexer implementation.

7

@AbdallahElYaddak what is the schema definition for your object?
Sounds like you are using some kind of compound field.
I don't think there is an index type that would work out of the box index for this.
If you have custom code on your content type then you can have something like

@property
def priority_token(self):
   return self.priority['token']

and then add a field index called priority_token

and then you can search using "priority_token=1".

basically search is like BigTable, it's flattened data model for search.

It would be nice though if FieldIndex did allow you traverse inside dicts or subobjects...

1 Like
8

To speed up seaching, we use indexes to store 'the most important parts of content'.
So, for a content (I happen to know), only one (sting or number) is saved to the index.

In other words, you need to serch for priority=1 (or '1').
This will give you all object that have priority 1.
If you need to know the title of the 'priority', it is probably better to first 'get the (priority) vocabulary' and see 'what the title of priority is. This will prevent having a large index which slows down the site.

Alternatively, you can probably get the title from the objects after you have 'searched for them'.

You can ping me directly if this does not make sense.

9

Sorry for not providing more info in my last reply. What I meant is that this suggestion did not work for me:

Which means nor trying with priority = 1 worked, nor priority= '1 Important'
I also tried using ' and " to enclose the search term. That did not work too.

So, I think if that is not indexed into a new field like priority_string=1, that search can't work. I hope I am wrong though because this makes sense:

10

It seems I could not address my reply correctly. It was meant to answer Espen's suggestion, which was specific. So, I did not add codes to that reply.

I only have access to using the API. I sent your FieldInex answer to who can add that to the API. Thank you.

11

UPDATE:
While it did not work with priority, it worked as you suggested for:

"assigned_to": {
    "title": "Aaa",
    "token": "aaa@bbb.ccc"
}

Adding assigned_to=Aaa parameter to the GET request works.

So, there must be something different with priority object.

12

In the database, (a lot of) different 'things' are stored.
This means that the database can get big, and searching it can take time.

To make things faster, Plone uses 'indexes'. The reason for using indexes is 'faster search'.

Imagine we have a content item (of type 'ToDo').
This has a field 'assigned to'.
For 'SomeToDoItem', the 'assigned_to' field is (for example) storing the ID of the 'assigned user'. This way, the view (template) of that shows 'SomeToDoItem' can 'look up' user '123' and show his/her Name, Email, Picture etc.

But: Storing all those 'properties' on the 'SomeToDoItem' is unpractical (the email / picture might change) and slow (since it would store information that is 'saved someehere else' (in the profile of user '123').

When using 'indexes', it is best to store as little info as possible, and then 'look up the other info of that user with the Api (or similar).

So, about the 'assigned_to=AAA' is the 'right way to get the user. After that you 'look up user 'AAA' and gets his/her email, phone, picture or whatever, probably by something like: 'mysite/plone/@users/somebody"

https://6.docs.plone.org/plone.restapi/docs/source/endpoints/users.html**strong text**

About the 'priority' and 'priority_string' (I happen to know):

Because there is/was a 'bug' in collective.collectionfilter, there are two indexes ( since 'Bool' and 'numbers' did not work well with the filter')

Basically, these indexes are the same, but one is stored as a number and one is stored as a string.

So, the index 'priority' is a number ( 1, 2, 3)

and the index 'priority_string' is a string ( '1', '2', '3')

About 'not worked': Make sure that there is content with 'that priority' (try priority_string="2" or priority=3 )

1 Like
13

Thank you so much for the explanation, Espen. I really appreciate that.

Adding this parameter: prioritystring=1 worked. But not priority=1.
And thanks to you, I know why:

And that's why a separate property prioritystring was created.

How to mark this as solved?

14

YES

Unfortunately, for now both indexes has to be present.

This is because 'some stuff in Plone' works with the string index and others with 'int' (number).

For example: If we add a Collection / smart folder, it is possible to show items with 'priority' > 1 (or priority between 2 and 4 ). For this 'mathematical operation', it has to be a number.

For CollectionFilter, unfortunately it does not 'work', since 'clicking on the'
Priority
1
2

Tries to find items with '1', not 1.