New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Limit Size of List #6
Comments
Hey @ehoch, sorry for the delay, totally missed the notification. Initially, it feels like a pretty significant edge case that would bring in a good deal of complexity, e.g. what happens if your limit is 100, but you set the position of an element to 150? I know at some level that can be the responsibility of whomever is using the gem, but it seems like it opens the door for some unexpected behavior. If we can handle those in a very friendly manner, I'm definitely open to consider the pull, though. |
For something like that? I would just set your position to 100 and make the old 100 nil. I realize it will definitely add some complication and have some interest edge cases, but aren't that what tests are for? Just wanted to make sure you were down before I put in the necessary time. |
Honestly, it still feels like it's opening the door for some headaches for people using the gem. I'd rather address the performance concerns directly. What kind of performance are you getting on 50k records? Another option would be to create a column and set it as the scope on the acts_as_restful_list. Then, just set it for the 100 records you care about. Would that solve your problem? |
Well, performance wise it's simply a limitation of SQL. You're updating 50,000 rows. For example: SQL (1939.9ms) UPDATE Not sure there's a fix there. Unfortunately I can't scope it. It's still the entire set of posts I need for the above example. I mean, I need my webmaster to be able to pick 6 featured posts for example and choose their order. Then elsewhere, I want to be able to paginate through the first 100. |
Hey Eric, After thinking about this some more and talking it over with a few people, I think adding this would add too much complexity that, given how frequently people will need it, isn't really justified at this point. It seem like your example is a pretty edge case. Even then, though, promoting an item from 50002 to the top of the list is probably rare enough that you could handle it in an asynchronous process just fine. Definitely feel free to fork the project and make the changes there. If it looks good and I hear more need for this, I'd be happy to reconsider. Cheers, |
Okay fair enough. Thanks for the great gem! |
Would you accept a pull request if I wrote an optional ability to set a limit on how large of a list a model keeps track of? As in, if you have 50,000 records and set a limit of 100, it only tracks the order of the first 100.
The reason I ask is because I actually do have a table with over 50,000 records and don't care about anything more than the ordering of the first 10 really. Unfortunately, acts_as_restful_list is much too slow with that many records.
Thoughts?
The text was updated successfully, but these errors were encountered: