Is there a limit to the number of items to sort?

[brunoprietog]

Hi, thanks for all the work on this gem.

Reading the internal part about how ranked-model works, and the limits of the integers that are used, I have the doubt if there is a limit of items that can be sort.

If there is a limit, in that case it is convenient to use acts_as_list? Is the performance difference too much?

Thanks, sorry for asking here

[brendon]

Hi @brunoprietog, the limit would be very large; essentially the total integer space (positive and negative) within the upper and lower limits of the column in the database). The problem with ranked-model is the need to rebalance quite quickly when appending items to the end of the list all the time. This is because the decrease in gap between items is exponential (given we're halving it each time). This just triggers a rebalance though, so you can still keep storing more, there's just a computation penalty every 30 or so added records (off the top of my head). If you're seeding data you could bypass ranked-model and just compute the gap required to evenly space all the items (if you know how many you'll have) then insert them with specific integer values. ranked-model can then be used to manage the list from there.

Hope that helps? I'll leave it to you to close if you're happy with that answer :D

[brunoprietog]

Great, I understand. Another question I have is if the row_order numbers are different for each different same_with. For example, for each todo_list_id. In that case, each todo_list would be limited to todo_list_items? Or the limit is applied based on the total todo_list_items rows regardless of other columns or foreign keys?

I ask this because if that's how it works as I think about it, then it would be very strange if the limit would be a problem really. But if the limit is applied on the total it does concern me.

Do you recommend to use acts_as_list even in that case?

Sorry, I have the feeling that this question is a bit obvious.

[brendon]

Don't apologise @brunoprietog, those are good questions :)

The position values in the database are scoped to the list context so you won't have to worry about collisions or depleting the available values if your lists aren't massive. I'd say other things would fail before you ran out of room (e.g. the queries may not be overly efficient :) )

acts_as_list has its own use cases. I actually wrote a concern recently that does what acts_as_list does but in a more robust manner (with a uniqueness constraint on the position column). It's not ready for the prime time yet but I might release it as a gem once all the kinks are ironed out. It's suprising how complicated things get once you introduce scopes and Rails :D

[brunoprietog]

Great, thanks! I'll be looking forward to it