Opened 13 years ago

Last modified 13 years ago

#112 closed defect (FIXED)

Previous / next navigation on media pages

Reported by: Jef van Schendel Owned by: Jef van Schendel
Priority: minor Milestone: 0.0.3
Component: programming Keywords:
Cc: Parent Tickets:


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 <>`_.

Change History (16)

comment:1 by Christopher Allan Webber, 13 years ago


    > 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)? 

`\_thread/thread/749302aebc0071b2 <>`_

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

comment:2 by Christopher Allan Webber, 13 years ago

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..

comment:3 by Christopher Allan Webber, 13 years ago

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.

comment:4 by Christopher Allan Webber, 13 years ago

Component: Programming
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.

comment:5 by Caleb Davis, 13 years ago

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

comment:6 by Caleb Davis, 13 years ago

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:
        next = mediaentries.find(same uploader, greater_than_time).sort(created time)[0]
      except IndexError: #??
        next = None
        prev = mediaentries.find(same uploader, less_than_time).sort(-created time)[0]
      except IndexError: #??
        prev = None
    # otherwise, complicated code
      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
          # 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 > || (time > current.time))

comment:7 by Caleb Davis, 13 years ago

I have a functional branch here -
[\ :sub:`cfdv/mediagoblin/cfdvs-mediagoblin/commit/9c0fe63fadc848b5154c7c1d4b2ff72dd05bc1c6](`\ 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, 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!

comment:8 by Christopher Allan Webber, 13 years ago

Milestone: 0.0.3
Owner: set to Caleb Davis

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%.

comment:9 by Caleb Davis, 13 years ago

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

comment:10 by Christopher Allan Webber, 13 years ago

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

Thanks for pointing out the missing placeholders.

comment:11 by Jef van Schendel, 13 years ago

Owner: changed from Caleb Davis to Jef van Schendel
Status: NewIn Progress
Alright, awesome. Time to make them look decent. Assigning to me
and 0.0.4 targeted. Thanks Caleb!

comment:12 by Caleb Davis, 13 years ago

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

comment:13 by Jef van Schendel, 13 years ago

Status: In ProgressClosed
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!

comment:14 by Caleb Davis, 13 years ago

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

comment:15 by Christopher Allan Webber, 13 years ago


comment:15 by Will Kahn-Greene, 12 years ago

The original url for this bug was .

Note: See TracTickets for help on using tickets.