Forum ‹ BigDB ‹ Paging through list of objects using LoadRange

[jasonredhawk]

In my BigDB table, I have 100s of entries. I want to use LoadRange to load the first 10 objects, then page to the next 10 objects.

Code: Select all

public function loadRangeOfMaps(pageIndex:int, totalLimit:int):void
{
    PlayerIOConnection.client.bigDB.loadRange("maps","state",["public"], pageIndex*totalLimit, null, totalLimit, function(_mapItems:Array):void
    {
        for (var i:int  0; i < _mapItems.length; i++)
        {
            trace(" > " + _mapItems[i].mapName);
        }
    }
}


Then later, I want to use the loadRangeOfMaps function to page through my list of maps like this:

Code: Select all

loadRangeOfMaps(2, 10);


From the example above, what I want from the function above is load the map items between 20-30.

Of course, it's not working. How do I accomplish this? Thanks in advance!

[MoDDiB]

I need to do the exact same thing is there really no way to accomplish this ?
It sounds like something a lot of people will need especially because there's a limit of 1000 items returns !

If the only way to do this is a new index to query how to be sure the index is unique and autoincrementable ?

[Guillaume]

It seem you cannot achieve that directly.

However, as you can load Range by Index, you may try to create your own index pagination.
Create an indexed property like "index" as an integer or a string, and set this index when you save the data initially.

Also, you may try to save the last computed index on an other table.
This way you know what is your max index in the table, and so you know how many time you can call your pagination.

Also i was talking about indexing a string...But why ?

Well, it depend of one thing: Do you plan to sort again the data in the futur, or not ? If yes, and if its related to new data, there is one difference between a list ordered ascending as a string and a list ordered ascending as an integer.

Here the example:

As an integer: 1 < 110 < 111 . Imagine you add a new value that would be after 110, so 111. In this case you must also modify the 111 data to transform it as a 112...But there is an other index next maybe ? Hard a very long to resort everything !

As a string you can trick a little, because the sorting is not based on a integer value, neither the length of the index, but the weight of each caracter !

So you can do this:

As a string: 1 < 110 < 1101 < 111 . This is totally correct ! Because even if it look like as a decimal it would be longer, as a string, the third caracter of 1101, '0' weight is less than the third character of 111, '1'. So 1101 is lesser than 111, compared as string value !

This way, you may resort your data on BigDB even without modifying last computed data index. Btw, maybe you don't need all theses things !

I would recommand you to create a BigDB table dedicated to indexing, with like 2 property you will reuse and update:

lastComputedIndex: if used as a string like i said, its the last index you saved in DB. Its useful because you can know if the last data was also prefixed by an other caracter if its the case.
maxComputedIndex: Just an integer count of how many data you saved on this table. This way you know from where you may continue to index your data, you can know how to stop reading pagination from client side.

Also keep in mind that you may have some "conflict" if you have a lot of data and that my prefixing scenario can collide with the normal behavior of your indexing. So you may have to do some custom less weighted caracter trick in your index names, in order to not conflicting with real upper indexed value. I don't know yet, but for exemple, you may instead try to use a dot as new separator, and this way, never colliding between some integer logic value.

The dot is less weighted than numbers, see the dot value, as a decimal, (46):
https://upload.wikimedia.org/wikipedia/ ... de.svg.png

That mean my previous example would not be this:

1 < 110 < 1101 < 111

But this:

1 < 110 < 110. < 111

Be creative !
It will be fine then !

[Henrik]

The simplest solution is to put a timestamp property on each object and index by that.

To page through the table, use the last encountered property value as the starting values for the next LoadRange call.

[MoDDiB]

Thank you all I will try this.
But I really would have preferred be able to page directly with the api ( in order to directly get the 500th page for instance ).

[Guillaume]

I think its the cost of having a such dynamic table system !
You are not entitled to a strict and hard to update format like a real SQL Database.

I think BigDB is something similar to some NoSQL technologies, but i'm not an expert on that...