Previous / next navigation on media pages

[Jef van Schendel]

We'll need a navigation area on the media pages to browse a user's
media. We can start simple, by adding "previous" and "next" links.

I don't have any idea to do this, so here's a humble request to
anyone capable. Creating two regular links to move back and forward
through a user's media would be great, then I can style them.

To start with, they'll look
`something like this <http://schendje.fedorapeople.org/temp/Screenshot-1.png>`_.

[Christopher Allan Webber]

::

    > If yes, why can't you use a created timestamp, search on
    > items larger than the timestamp of the current object and
    > limiting to the result set to one row (same for previous)? 

`http://groups.google.com/group/mongodb-user/browse\_thread/thread/749302aebc0071b2 <http://groups.google.com/group/mongodb-user/browse_thread/thread/749302aebc0071b2>`_

that's probably the right way to do this? :)

[Christopher Allan Webber]

Also worth reading that reply:

::

    Just watch out. If documents are inserted at the same time as they are
    being read, you could end up with partial results during newly
    inserted queries, and thus its not a perfect way to ensure you get all
    next set of records, as more could have been inserted with the same
    timestamp in the interim.
    
    For this, ended up needing to use capped collections and natural order
    with skip.. it was the only way to guarantee that pagination works
    exactly the same in every case, even while new data is pouring in from
    multiple clients.

I don't think we can use capped collections, unfortunately..

[Christopher Allan Webber]

A vague idea of how to solve this:


-  Instead of querying on say, timestamp greater than the current
   document, query on greater or equal to
-  Present document will be in that list. Find whichever document
   comes **immediately after** the present document.

That should work and not be very intensive.

[Christopher Allan Webber]

Currently a programming task. Setting to two hours estimated time
just in case the above stuff is slightly confusing, but I think
this should be pretty easy.

[Caleb Davis]

I'm confused whether our custom indexing solution alters how I
should approach this problem relative to what I find in mongodb and
mongokit docs

[Caleb Davis]

Chris suggested this pseudocode in IRC:

::

    # If there's just one entry at this time, we can use the "easy" next
    # and previous (if they exist)
    if mediaentries.find(same uploader, SAME time).count() == 1:
      try:
        next = mediaentries.find(same uploader, greater_than_time).sort(created time)[0]
      except IndexError: #??
        next = None
    
      try:
        prev = mediaentries.find(same uploader, less_than_time).sort(-created time)[0]
      except IndexError: #??
        prev = None
    
    # otherwise, complicated code
    else:
      next = None
      found_orig_entry = False
      for entry in mediaentries.find(same uploader, less_than_time).sort(created)
        if not found_orig_entry:
          if entry == original entry:
            found_orig_entry = True
        else:
          # we found the entry on the last round, so this one's it
          next = entry
    
      # and same for previous, in reverse direction

Elrond suggested sorting on the objectID. Specifically, for the
'next one':

::

    ((time == current.time and id > current.id) || (time > current.time))

[Caleb Davis]

I have a functional branch here -
[https://gitorious.org/\ :sub:`cfdv/mediagoblin/cfdvs-mediagoblin/commit/9c0fe63fadc848b5154c7c1d4b2ff72dd05bc1c6](https://gitorious.org/`\ cfdv/mediagoblin/cfdvs-mediagoblin/commit/9c0fe63fadc848b5154c7c1d4b2ff72dd05bc1c6)

I made the needed links, and put some TODO comments in the spots I
imagine will be filled as someone else makes it pretty.

I don't like the code duplication in models.py, and I tried to move
it out into the template but I couldn't use unicode there unless I
added it to the global jinja2 environment, but even then the links
didn't come out right. Perhaps I should make an internal function
to encapsulate the repeated code. Feedback is most welcome!

[Christopher Allan Webber]

Merged.

I'm not entirely comfortable about not sorting on date and time..
I'm not sure we can guarantee things when there end up being
multiple servers with multiple submissions happening, etc. But for
now I suppose it's no huge deal. We can always commit that later.

I'm not closing this, but I am moving it to 80%.

[Caleb Davis]

What's the failure scenario when multiple servers get involved?

Also, this ticket still needs next, prev, next-greyed-out, and
prev-greyed-out images instead of my place-holders

[Christopher Allan Webber]

Failure scenario is you simply can't be sure that the previous/next
in the order will be the same as the previous/next in the gallery,
because you can't totally be sure they're sorted exactly on
timestamp.

Thanks for pointing out the missing placeholders.

[Jef van Schendel]

Alright, awesome. Time to make them look decent. Assigning to me
and 0.0.4 targeted. Thanks Caleb!

[Caleb Davis]

I see re: failure scenario. I think synchronizing the prev/next
ordering between the user page and the gallery is an additional
ticket. Whaddyasay?

[Jef van Schendel]

I've styled the navigation buttons, so I'm closing the ticket.

I think issue is specific/different enough to open a new ticket
for. :)

Thanks again, Caleb!

[Caleb Davis]

awesome, Jef! I can't wait to see/use it.

[Will Kahn-Greene]

The original url for this bug was ​http://bugs.foocorp.net/issues/401 .