Optimizing default item sort query

Omeka S Development
1

To all, but particularly the developers :slight_smile:

I am trying to optimize the sort queries for the default “Browse Item”. Aside from all the other context, what I am focused on right now is trying to locate where in the application code the default browse item query is constructed. I feel like I’ve found it before! But can’t any longer, maybe it changed in v1.4.

An example query from MySQL service query logging:
DEFAULT BROWSE ITEM SORT QUERY

SELECT r0_.id AS id_0, r0_.is_public AS is_public_1, r0_.created AS created_2, r0_.modified AS modified_3, r0_.resource_type AS resource_type_4, 
r0_.owner_id AS owner_id_5, r0_.resource_class_id AS resource_class_id_6, r0_.resource_template_id AS resource_template_id_7, 
r0_.thumbnail_id AS thumbnail_id_8
FROM item i1_
INNER JOIN resource r0_ ON i1_.id = r0_.id 
GROUP BY r0_.id ORDER BY r0_.created DESC, r0_.id DESC 
LIMIT 32 OFFSET 32

And here is how you would do it if you needed ASC order by dcterms:identifier rather than the default - again, an example query.

ADVANCED SEARCH/SORT QUERY FOR BROWSE ITEMS

SELECT r0_.id AS id_0, r0_.is_public AS is_public_1, r0_.created AS created_2, r0_.modified AS modified_3, r0_.resource_type AS resource_type_4, 
r0_.owner_id AS owner_id_5, r0_.resource_class_id AS resource_class_id_6, r0_.resource_template_id AS resource_template_id_7, r0_.thumbnail_id AS thumbnail_id_8 
FROM item i1_
INNER JOIN resource r0_ ON i1_.id = r0_.id
LEFT JOIN value v2_ ON r0_.id = v2_.resource_id AND (v2_.property_id = 10) 
GROUP BY r0_.id
ORDER BY GROUP_CONCAT(v2_.value  ORDER BY v2_.id ASC) ASC, r0_.id ASC 
LIMIT 32 OFFSET 288

I am trying to do some clever GREPping to find which file the query is constructed in, but mostly I’m getting results in “/Api” and “/doctrine” which are obviously not where the specific views are being constructed.

Any pointers appreciated!

2

The default queries, and most all queries, are created by API “adapters” in the Api folder. The AbstractResourceEntityAdapter and AbstractEntityAdapter are responsible for most shared query-related code for resources.

3

Ah that would explain it! I think that wasn’t the case in an earlier version? I was thinking Api was only for external consumption not internal.

4

In Omeka S with just a few exceptions the same “Api” core is used both internally and for the REST API. S has always been this way, but it’s a significant departure from Classic.

1 Like