On Oct 30, 5:19 am, "Paul Johnston" <[EMAIL PROTECTED]> wrote: > > > But please, make it simple to turn it on so that the DBs that support that > > > feature can benefit of it. > > > The default would certainly be "on", to prevent breakage. > > Sounds like a good feature. I'd suggest off by default. If it's on by > default, I expect few people would turn it off when their DB does support > limit/offset.
On by default, or off by default? It seems like it should ideally be on by default for databases that need it, and off by default for the rest, with the ability to override the default by setting a variable in the config file. I've attempted to implement that strategy by inspecting the sqlobject.dburi and sqlalchemy.dburi config variables the first time that @paginate() is used, and extracting the database name. If the name matches a hard-coded list of databases that don't implement offset, then the simulate_offset code is used, and a warning is logged, "simulating OFFSET, paginate may be slow". The paginate.simulate_offset variable, however, can be set to True or False to override the defaults. I briefly scanned through both SQLAlchemy (trunk) and SQLObject database driver code, and made lists of which drivers appear not to support offset. The results aren't always what you'd expect, because some drivers (like Oracle in SQLA) emulate offset even though the database doesn't support it. I made two lists, rather than one, because for a given database, one driver might emulate offset while another driver doesn't. The lists I came up with are: _so_no_offset = 'mssql maxdb sybase'.split() _sa_no_offset = 'mssql maxdb access'.split() If anyone has any additions or corrections to these lists, please let me know. For that matter, if anyone sees any other flaws in this scheme, let me know that, too! > BTW, someone proposed a patch to let SA/MSSQL fake limit/offset, it was > based on the Oracle approach. I haven't applied the patch as yet, but it > will happen eventually. I believe that patch only supports SQL Server 2005, so SQL Server 2000 installations will continue to need a workaround. - Joel --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~----------~----~----~----~------~----~------~--~---
