Skip to content
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

Closed
ehoch opened this issue Feb 20, 2012 · 6 comments
Closed

Limit Size of List #6

ehoch opened this issue Feb 20, 2012 · 6 comments

Comments

@ehoch
Copy link

ehoch commented Feb 20, 2012

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?

@treybean
Copy link
Member

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.

@ehoch
Copy link
Author

ehoch commented Mar 14, 2012

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.

@treybean
Copy link
Member

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?

@ehoch
Copy link
Author

ehoch commented Mar 14, 2012

Well, performance wise it's simply a limitation of SQL. You're updating 50,000 rows. For example:

SQL (1939.9ms) UPDATE posts SET position = (position + 1) WHERE (position >= 1 AND id != 50119 AND position < 50002)

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.

@treybean
Copy link
Member

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,

@ehoch
Copy link
Author

ehoch commented Mar 20, 2012

Okay fair enough. Thanks for the great gem!

@ehoch ehoch closed this as completed Mar 20, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants