On Sun, Mar 20, 2011 at 6:38 AM, Wichert Akkerman <wich...@wiggy.net> wrote: >>> New issue 63: Regression: paginate loads whole table when given >>> SqlAlchemy object >>>
> Yaiks - that change will effectively kill any site which does pagination > over a large SQL table, so reverting it would be a good start. I don't see > why the original line would raise that TypeError though. Did the bug > submitter contribute a test to demonstrate that? It looks like he is > strangely behaving collection type. I reverted the patch in 556b55e75dd6, and implemented Marcin Kuzminski's slice test posted to the bug report. Can somebody try checking out WebHelpers dev and make sure it works in your application, especially if you have some large tables to try it against? I'll release 1.3b2 in a day or two after people have had time to test it. (https://bitbucket.org/bbangert/webhelpers/issue/59/webhelperspaginate-error-line-434) Sprox objects appear to be unsliceable and therefore incompatible with paginate. I also discovered that SQLAlchemy queries and selects also don't have .__getslice__, but that's OK because their wrapper class emulates it. So i had to move the slice check below the SQLAlchemy check. I wrote some unittests for various collection types, and discovered there seems to be a bug with SQLAlchemy select objects. https://bitbucket.org/bbangert/webhelpers/issue/64/paginate-sqlalchemy-select-test-fails The wrapper's .__len__ returns the query's rowcount directly, which is -1, which makes Python choke because len() isn't supposed to return a negative number. The test is commented out but is tests/test_paginate.py#TestSQLAlchemyCollectionTypes.test_sqlalchemy_select . Christoph, can you try the test and see if the wrapper is buggy or the test is wrong? I don't know how long it's been this way; maybe nobody uses paginate with select. https://bitbucket.org/bbangert/webhelpers/issue/64/paginate-sqlalchemy-select-test-fails In the long term I think paginate should be refactored to eliminate the pseudo-list layer. It makes it hard to tell what the backend is doing, and how Python's special methods are interacting with it, and how the collection's special methods may be complicating it further. I'd like to replace the list-like wrappers with straightforward helper classes that do their business directly and return a Page or the data to construct a Page. The Page could remain a list subclass but it would be fully static, not collection-aware. Furthermore I'd like users to be able to provide their own helper classes for third-party collection types. There have been patches to add PyMongo, CouchDB, and now Sprox to paginate, but we can't add everything. Better to go with autonomous helper classes. But this is a longer-term project, it's not something I can do right now. Christoph, what do you think? https://bitbucket.org/bbangert/webhelpers/issue/65/refactor-paginates-pseudo-lists -- Mike Orr <sluggos...@gmail.com> -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
