Query for content sorted by getObjPositionInParent in multi level objects

Plone Support
1

I created multi level content like this:

/mysite/folder1/document1
/mysite/folder2/document2

Envoking http://myhost/mysite/folder_contents provides the expected order:

folder1
folder2

Running a Python script in ZMI:

brains = context.portal_catalog(
    portal_type='Document',
    sort_on='getObjPositionInParent',
    sort_order='ascending'
)
return [item.id for item in brains]

returns ['document1', 'document2']

Running the script again after reordering via drag and drop to
folder2
folder1

returns ['document1', 'document2']

But i would expect ['document2', 'document1'].

After updating the catalog the result of the script is:
['document2', 'document1']

Is something wrong with my expectation?

System:
Plone 5.2.5 (5213)
CMF 2.5.4
Zope 4.6.3
Python 3.9.9 (main, Nov 16 2021, 19:02:50) [GCC 8.3.0]
PIL 6.2.2 (Pillow)
WSGI: An
Server: waitress 1.4.4

Thanks!

2

This makes only sense when you are interested in the ordering within one folder, not within different folders.

3

I see the point.
But there is also an inconsistency in the catalog after reordering of folders in my opinion:
Why does this kind of query behave differently before and after updating the catalog? In other words: What is the catalog update doing in the catalog what should be done by the reordering? This inconsistency made me question: What i have to expect using index sort_on='getObjPositionInParent' using multi level objects.

4

Does this happen in a fresh Plone instance? Also, the position in folder_contents is catalog based, so it is strange you see the items ordered correctly in folder_contents and the getObjPositionInParent metadata being wrong. Can you also print getObjPositionInParent and check the values in portal_catalog? Can you reorder and the reload the page to see if the reordering is persistent?

Beware that folder_contents permits a temporary reordering (just visual).

5
  • yes, this does happen in a fresh Plone instance and fresh Plone site
  • the value of getObjPositionInParent in portal_catalog is an empty list for all of the tested objects (folder1, folder1/document1, folder2, folder2/document2)
  • yes, reordering in folder_contents via drag and drop is persistent
6

Nothing. The feature was made to support ordered folders and access them fast. It was never meant on multi level. In catalog both documents have the order 1. Thus, the result is ordered by this number,

if you need a meaningful result over multiple folders (like walking a subtree), the path index has better options.

1 Like
7

Thank you all for your answers.

  1. Yes, my initial expectation using getObjPositionInParent was the use case of a single folder. After some tests multi level seemed to work too, but this is probably a random result of the implementation. So i will return to the initial expectation.

  2. Whats about the inconsistency of the catalog after reordering folders via drag and drop as described above? This seems to be a separate issue. Do we need a deeper examination?

8

It is not an inconsistency. getObjPositionInParent is 1 in both cases, so the order depends on internal structure of the index (can be that the lastest modified document goes up or down in the list).

1 Like
9

My point is:
Why does this kind of query behave differently before and after updating the catalog? In other words: What is the catalog update doing in the catalog what should be done by the reordering via drag and drop?

10

getObjPositionInParent is a gopipindex.

From the docs:

A GopipIndex fakes the formerly used "getObjPositionInParent" index
by retrieving the necessary information directly from the search results'
containers. It works as a drop-in replacement and makes expensive indexing
of each item's position unnecessary.

This index is expensive (wakes up all the folders containing the query result objects and call getOrdering on them), it is mainly used only on folder contents view because of this.

11

Because when get the results from a query, and you've 2 items with the same values to sort_on, you merge some list and the order depends on how the internal structures are created and merged.

Sorting on getObjPositionInParent from different folder works but it is not useful. It is only when you use it on a single folder.

12

I would not expect unsortable list of entries to be sorted. This is to be expected random. The catalog has some query optimizers too, so even the order the indexes are queried are probably different from query to query. Sort it one something meaningful or let it. Sorting 1,1,1 may output 1,1,1 or 1,1,1 right :wink: ? One can't tell, but all valid.

1 Like
13

@maha

If you want to play a bit, check this:

1 Like