missing pagination in list generated by elgg_view_entity_list

i am creating a page that renders a standard list of entities from a pre-existing array of entities here.

i have used the code:
            $options = array(
            'offset' => max(get_input('offset'), 0),
            'limit' => 10,
            'full_view' => false,
            'list_type' => 'list',
            'pagination' => true,
        $content = elgg_view_entity_list($entity_list, $options);


i am seeing that there is no pagination rendered, just one large list (no size limit is applied either)..
anyone know why that may be?

  • If you're getting 79 entities, then dropping 69 of them to display the remaining 10 that's very inefficient.  What happens when your list has 300 entities?  1000?  more?

  • this is a page that is showing the list of related items for a given entity (showing all the items rather than a small subset). so ultimately it is no more innefficient than the code that already runs on the entity pages already in the related-items plugin in that the full list is being calculated anyway to produce the data to be used for any item in the list.

    i don't have a large dataset to test this with presently.. so far the code is fast enough on my own site.

  • i realise that a custom sql query would be more efficient than the mixture of sql and php i am currently using in the related-items plugin.. i wanted to test and see how efficient the code is without custom sql before doing that.. mainly because i am unfamiliar with mysql nuances and the elgg dbase design.

  • How are you determining the relatedness of objects?

    If it's user-defined I would have it by relationship, then you can just use elgg_list_entities_from_relationship

    Unless there's a defined maximum of items are possible it's generally a bad idea to get/list all entities, you'll run into memory issues.  If there's no reasonable maximum you should display a subset with a defined limit and provide a link to view more.

  • presently the plugin uses tag matching only.

    the query i am using is presently is elgg_get_entities_from_metadata, which retrieves all entities that have matching tags to the current item and other possible restrictions are allowed to the query by admin settings such as entity age and owning user (amongst others) - in this way the size of the list can be limited according to capacity of the server. the reason that i have used the array_splice for the related list is that the list is sorted by similarity (amount of matching tags) and i have coded the similarity algorithm in php as i was not clear on an effective way to calculate it with pure sql (except for using transact sql which i am not familiar with in mysql); so the list that is returned by the elgg getter function will always be the full list than then needs to be refined.

  • ok, well for the record - that's not scalable at all, you'll chew through memory in no time as you get more tags and more content.  This needs to be done at the sql level.

  • 'that then needs to be refined' ;)

    yes, not the most efficient approach. i am aware that pure sql is preferable; i will do that in a future version.

  • i've now resolved this in the 'elgg way' and the processing is shifted to sql. :)
    thanks for assisting.

  • Care to share some of this code? Seems useful.