As an added note, I could use some help in creating the database specific keywords lists.
-Thadeus On Wed, Feb 3, 2010 at 11:43 AM, Thadeus Burgess <thade...@thadeusb.com> wrote: > Ok take a look at the following proposed changes > > http://code.google.com/r/thadeusburgess-web2py/source/detail?r=c416459252755abde998e923021188335924e02c > > I made it DRY. Also you pass a list of options. Here is example usage > > db = DAL('sqlite....', pool_size...., check_reserve=['common', > 'postgres', 'mysql']) > > check_reserve is a list of backends to use, with two extra terms 'all' > and 'common'. It defaults to None, which performs no check. > > If you set common, it will check the KEYWORDS_COMMON list, and throw a > SyntaxError. > > If you set all, it will check the KEYWORDS_ALL list, and print a > warning message. > > If you set an adapter name, it will check the adapters KEYWORDS and > throw a SyntaxError. > > This only effects the new dal, (dal.py) since i do not have time to > implement this for sql.py. > > > As Jonathan Lundell suggests in his mercurial post, you can code > review this change. Once we are happy, Massimo can pull the changes > in. > > -Thadeus > > > > > > On Tue, Feb 2, 2010 at 4:44 PM, Richard <richar...@gmail.com> wrote: >> This is awesome - thanks Thadeus! >> I develop with sqlite but deploy on postgres/GAE and almost always get >> caught by this. >> >> >> >> On Feb 3, 9:10 am, Jonathan Lundell <jlund...@pobox.com> wrote: >>> On Feb 2, 2010, at 1:19 PM, Thadeus Burgess wrote: >>> >>> > 1. Its only in two places. Once for tablename, and once for fieldname. >>> > And then this needs to be done for sql.py just in case >>> >>> DRY >>> >>> >>> >>> > 2. Yes very chatty. What about the following? >>> >>> > DAL('sqlite....', pool_size=1, check_reserve=None) >>> > DAL('sqlite....', pool_size=1, check_reserve='common') >>> > DAL('sqlite....', pool_size=1, check_reserve='all') >>> > DAL('sqlite....', pool_size=1, check_reserve='postgres') >>> > DAL('sqlite....', pool_size=1, check_reserve='mssql') >>> >>> > This way we can define the level of check. Then the check will be >>> > placed in a function of db. db._verify_reserved_keyword(keyword) which >>> > will perform the checks based on the self.check_reserve. >>> > None would be no name checking, to keep backwards compatibility and >>> > for production systems. comments? >>> >>> Makes sense. How about accepting a list? >>> >>> >>> >>> > 3. How is it ambiguous, you hit the definition right on target. Its >>> > common SQL commands that without these commands you don't have SQL, >>> > and if you use one of these terms in the current system you get an >>> > OperationalError anyways. >>> >>> OK... >> >> -- >> You received this message because you are subscribed to the Google Groups >> "web2py-users" group. >> To post to this group, send email to web...@googlegroups.com. >> To unsubscribe from this group, send email to >> web2py+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/web2py?hl=en. >> >> > -- You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
