Forum ‹ BigDB ‹ Leaderboards with multiple pages

[LostBytes]

Hello,

I would like to implement leaderboards in my game that users can browse. I wan't to show all players, not only top N. I created necessary indexes on my table, but I don't see how to implement paging. loadRange allows me to specify start and stop values, not index (as in load player from position 100 to 120) and this doesn't help much. I could load all objects at the beginning and split it on client, but that will quickly become problem as number of users will go only up

[Henrik]

bigdb-f32/paging-through-an-index-t1527

Except my answer is a little bit wrong... The way to do it is to load N+1 items, but only display the first N. If you get N+1 back, you know there are more pages, and then you set the start value to the value of the N+1th item (which you didn't display), and load N+1 items again.

[LostBytes]

hmm... that might work, I will try that. Is there any way how to get total numbers of results for given key? so I can show users how many pages are there

[Henrik]

No, there's no count either.

However, realistically, this isn't really important. Almost all of your players will only look at the first page, some will flip through a few pages, but noone will actually care how many pages there are or or flip to the end.

[LostBytes]

Ok, so I tried to do as you said and I try load next page like this:

Code: Select all

G.client.bigDB.loadRange("PlayerObjects", "level", [lastValue], [lastValue, lastUser], null, 11,
   function(scores:Array):void{
      fillInValues(scores);
   }
);

last value is level of 11th user from previous load. I try use lastUser to make sure I load from correct position if there are more users with same level (not really sure if this is right way). Anyway, my problem is that above code fails with error:
Error: The index 'level' value no. 2 (index 1) must be of type: String

I don't really understand what path parameter is used for, but it is obviously needed. Only option when it is not giving me errors is when I try to add [lastValue, lastUser] as path, but then it returns 0 results (which I think is correct for this parameters).

What is proper way of doing this? I am kinda lost

[Benjaminsen]

You have configured your index to be a string index. (String indexes will only accept strings as search paramaters)

Reconfigure the index to use uints and it will work (It's the dropdown on the index setup)

[LostBytes]

My index contains Int (total xp) and String (username, to uniquely identify 10th user so I can start next page from him), lastValue is int and lastUser is String so it should work, or am I missing something?

[Oliver]

The arguments are:

loadRange (table:String, index:String, path:Array, start:Object, stop:Object, limit:int, callback:Function = null, errorHandler:Function = null):void

So, most likely, you wan to do this:

G.client.bigDB.loadRange("PlayerObjects", "level", [lastValue], [lastUser], null, 11,
function(scores:Array):void{
fillInValues(scores);
}
)

Best,
Oliver

[Henrik]

If you have a table with an index over columns a, b, and c, and you do a loadRange query with path = [s, t], start = u, and stop = w, that translates into getting all objects where a = s and b = t and c is between u and w.

If you do a loadRange with just start = s, that translates into getting all objects where a > s. So you apply the arguments in path to the properties in order, and then you apply the start/stop arguments as your actual range argument on the "next" property in your index.

What this means for you is that since score is the first property of your index, you should leave path empty, and put the previous last score as the start argument. Unfortunately, this also means that you can't use the last username as part of the loadRange call, and if several people have the same score, you'll get stuck.

This is a limitation in our client-side API. The first version of loadRange actually had start and stop as arrays, and in that version, all of this wouldn't be a problem. But we changed that, because we thought that version would be less intuitive as to what is returned. However, this problem is a pretty bad consequence of that which we didn't think of, so we'll be discussing this issue internally and see if we can solve it.

In the meantime, you can work around it pretty easily. The problem only occurs if a lot of objects have the same value on an indexed property, so you can fix this by making sure they don't. In your case, you could make a property called SortedScore of the type Double, and set the integer part of that value to the actual score, and the decimal part to either a random number or some sort of simple hash of the username. Then you just add an index on this property, and since all values in this index are unique, you should be able to page through it using the technique described at the top without any problems.