Yes, I decided to just have like
POSTGRES for reserved words and POSTGRES_NONRESERVED, so you can check
both if you so desire.
To check nonreserved keywords as well then just append _nonreserved
after the adapter name
check_reserved = ['postgres', 'postgres_nonreserved']
-Thadeus
On Fri, F
On 5 Feb, 03:19, Thadeus Burgess wrote:
> A quick question, what is your opinion on non-reserved keywords ?
> Should they be included, excluded, separated ? non-reserved words are
> acceptable and do not get in the way of your queries.
Re: "Non-reserved":
It seems that the definition of non-rese
http://code.google.com/r/thadeusburgess-web2py/source/detail?r=63967d6739efa4a3b60c909a82f981ca2f464028
Ok take a look at this now. I am happy with this. It only adds around
15kb added memory on my system, none if you have the check disabled.
I did move the keywords to a separate file. You were r
I now have postgres as well.
-Thadeus
On Thu, Feb 4, 2010 at 9:49 PM, Jonathan Lundell wrote:
> On Feb 4, 2010, at 7:19 PM, Thadeus Burgess wrote:
>
>> A quick question, what is your opinion on non-reserved keywords ?
>> Should they be included, excluded, separated ? non-reserved words are
>
On Feb 4, 2010, at 7:19 PM, Thadeus Burgess wrote:
> A quick question, what is your opinion on non-reserved keywords ?
> Should they be included, excluded, separated ? non-reserved words are
> acceptable and do not get in the way of your queries.
I don't know enough to have an opinion, but if the
A quick question, what is your opinion on non-reserved keywords ?
Should they be included, excluded, separated ? non-reserved words are
acceptable and do not get in the way of your queries.
-Thadeus
On Thu, Feb 4, 2010 at 9:18 PM, Thadeus Burgess wrote:
> I have firebird, and now mysql 5.5
>
I have firebird, and now mysql 5.5
-Thadeus
On Thu, Feb 4, 2010 at 9:14 PM, Jonathan Lundell wrote:
> On Feb 4, 2010, at 7:03 PM, Thadeus Burgess wrote:
>
>> Yes, there is much work to be done formatting each one of those lists
>> into a python tuple object.
>
> That part isn't so bad. I nee
On Feb 4, 2010, at 7:03 PM, Thadeus Burgess wrote:
> Yes, there is much work to be done formatting each one of those lists
> into a python tuple object.
That part isn't so bad. I need to know which ones you want. Here's MySQL 5.5:
'ACCESSIBLE',
'ADD',
'ALL',
'ALTE
Yes, there is much work to be done formatting each one of those lists
into a python tuple object.
-Thadeus
On Thu, Feb 4, 2010 at 7:16 PM, Jonathan Lundell wrote:
> On Feb 3, 2010, at 9:45 AM, Thadeus Burgess wrote:
>
>> As an added note, I could use some help in creating the database
>> spe
On Feb 3, 2010, at 9:45 AM, Thadeus Burgess wrote:
> As an added note, I could use some help in creating the database
> specific keywords lists.
http://drupal.org/node/141051
(I might have sent this before?)
--
You received this message because you are subscribed to the Google Groups
"web2py-
Hi Thadeus
I will send to you a file with the Firebird keywords via email. There
are differences between versions but I have tried to amalgamate all.
I am never quite sure about the non-reserved keywords, so I include
those too.
Note that my file will only include the Firebird words. Let me know
On Feb 4, 2010, at 11:08 AM, Thadeus Burgess wrote:
> Ok I get what you mean on changing sql to SQL. Misunderstanding, I
> thought you ment the keyword that was being thrown off.
>
> It will be an immutable array (tuple). The bracket just slipped in there :P
>
> Any ideas you could share on modu
Ok I get what you mean on changing sql to SQL. Misunderstanding, I
thought you ment the keyword that was being thrown off.
It will be an immutable array (tuple). The bracket just slipped in there :P
Any ideas you could share on modularizing dal.py that could allow this
to be in another file?
-Th
On Feb 4, 2010, at 9:02 AM, Thadeus Burgess wrote:
> 1. I do not capitalize name because this is actually what you are
> attempting to call your column, it could be 'select', 'Select',
> 'SELect'. It just seemed more logical to display the name that you
> wrote. Though it can be capitalized. I tho
1. I do not capitalize name because this is actually what you are
attempting to call your column, it could be 'select', 'Select',
'SELect'. It just seemed more logical to display the name that you
wrote. Though it can be capitalized. I thought you were referring to
the name of the database it was p
On Feb 4, 2010, at 8:19 AM, Thadeus Burgess wrote:
>> * Could we use 'check_reserved' instead of 'check_reserve'? It sounds more
>> natural to me.
>
> Why not.
>
>>
>> * Capitalize SQL in the error message strings
>
> It is capitalized.
raise SyntaxError, 'invalid name \'%s\': is a \'common\
> * Could we use 'check_reserved' instead of 'check_reserve'? It sounds more
> natural to me.
Why not.
>
> * Capitalize SQL in the error message strings
It is capitalized.
>
> * dal.py is already much too long. Could the wordlists live somewhere else?
No, they belong with their relative adapt
On Feb 3, 2010, at 9:43 AM, Thadeus Burgess wrote:
> Ok take a look at the following proposed changes
Comments.
* Could we use 'check_reserved' instead of 'check_reserve'? It sounds more
natural to me.
* Capitalize SQL in the error message strings
* dal.py is already much too long. Could the
If you do not use GAE it should work right now (cp dal.py sql.py)
Before I can make it work on GAE I need to abstract a little more
about insert and select.
Massimo
On Feb 3, 2:55 pm, Thadeus Burgess wrote:
> I know I didn't put one there.
>
> sql.py is way to spaghetti and will take longer th
I know I didn't put one there.
sql.py is way to spaghetti and will take longer than I have available
to make it work for sql.py.
When will we be able to use the new dal?
-Thadeus
On Wed, Feb 3, 2010 at 2:46 PM, mdipierro wrote:
> There is no check_reserved in gluon/sql.py.
>
> On Feb 3, 12
There is no check_reserved in gluon/sql.py.
On Feb 3, 12:33 pm, Thadeus Burgess wrote:
> A) Bring home the bacon !
>
> B) Every time unless you set check_reserve to None. In production you
> would have check_reserve to None.
>
> C) It should be a union, and that is exactly what its documentation
A) Bring home the bacon !
B) Every time unless you set check_reserve to None. In production you
would have check_reserve to None.
C) It should be a union, and that is exactly what its documentation I
added says. But we can't do a union until we actually create database
specific keywords until
On Feb 3, 2010, at 9:43 AM, Thadeus Burgess wrote:
> Ok take a look at the following proposed changes
I'll try to look at it later today; I'm off to work now.
Is the check made every time, or only when a table is actually being created
(or migrated)? The latter should be adequate, at least by d
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 wrote:
> Ok take a look at the following proposed changes
>
> http://code.google.com/r/thadeusburgess-web2py/source/detail?r=c416459252755abde99
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'
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 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.
>
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)
> DA
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
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', p
On Feb 2, 2010, at 12:48 PM, Thadeus Burgess wrote:
> You can view a proposed change, I have sent this to Massimo to look at.
>
> http://code.google.com/r/thadeusburgess-web2py/source/detail?r=e875496cc5978200fb6c0aa0f85a8df1a945df21
>
> I'm not sure what keywords we really want to use or not, b
+1 !
On Tue, Feb 2, 2010 at 1:48 PM, Thadeus Burgess wrote:
> You can view a proposed change, I have sent this to Massimo to look at.
>
> http://code.google.com/r/thadeusburgess-web2py/source/detail?r=e875496cc5978200fb6c0aa0f85a8df1a945df21
>
> I'm not sure what keywords we really want to use or
You can view a proposed change, I have sent this to Massimo to look at.
http://code.google.com/r/thadeusburgess-web2py/source/detail?r=e875496cc5978200fb6c0aa0f85a8df1a945df21
I'm not sure what keywords we really want to use or not, but this is a
starting point.
I added two lists to BaseAdapter
On Feb 2, 2010, at 9:31 AM, Thadeus Burgess wrote:
> Actually, we can use the Adaptors to hold specific keywords. So in
> DAL.__init__ can have for fields if fieldname in
> self._adapter.KEYWORDS then raise SyntaxError
It's be nice to have a way to take advantage of the keyword lists in Adapters
just as a note.
"role" is a sql keyword in ansi-sql, it will be a reserved word in the
next version of Transact-SQL/Sql-server, the other databases should be
fine, and is used in auth.
"table_name" is a reserved keyword in postgresql -
http://www.postgresql.org/docs/8.3/static/sql-keywords-append
Actually, we can use the Adaptors to hold specific keywords. So in
DAL.__init__ can have for fields if fieldname in
self._adapter.KEYWORDS then raise SyntaxError
-Thadeus
On Tue, Feb 2, 2010 at 11:28 AM, Thadeus Burgess wrote:
> Massimo, is there a better place (in dal.py) to place this chec
Massimo, is there a better place (in dal.py) to place this check. The
most logical I see is the Field.__init__ constructor.
-Thadeus
On Tue, Feb 2, 2010 at 11:27 AM, Thadeus Burgess wrote:
> I am working on this, I am integrating a list of reserved words into
> the Field() class.
>
> For now
I am working on this, I am integrating a list of reserved words into
the Field() class.
For now just the common SQL keywords, which I'm sure can be extended
to include backend-specific keywords.
-Thadeus
On Tue, Feb 2, 2010 at 11:08 AM, baloan wrote:
> Thanks David for the reference.
>
> Bt
Thanks David for the reference.
Btw, DATE is not marked as a reserved keyword on PostgreSQL and I can
create DATE columns using SQL or the admin tools (pgadmin).
Consequently I was doubly confused as DATE appears as a web2py
reserved word to me.
@Massimo: in your leisure time ;-) you may conside
I see so many of those I would use on a daily basis :(
-Thadeus
On Tue, Feb 2, 2010 at 8:41 AM, villas wrote:
> I get so frustrated when bitten by the "reserved words" problem.
> Unfortunately so many people only avoid the ones for their own chosen
> database, which is such a shame when it m
I get so frustrated when bitten by the "reserved words" problem.
Unfortunately so many people only avoid the ones for their own chosen
database, which is such a shame when it means their code is not
portable.
Anyway, this checklist is my favourite reference when I have a
doubt:
http://drupal.org/n
The first version of the new DAL is just a more modular version of the
current DAL. It will be easy to add this feature when done.
On Feb 1, 5:42 pm, Richard wrote:
> I just experienced the same problem using "app" on Google App Engine,
> which wasted some time - it will be neat when the new DAL
I just experienced the same problem using "app" on Google App Engine,
which wasted some time - it will be neat when the new DAL takes care
of these problems! (It will, right?)
On Feb 2, 8:48 am, mdipierro wrote:
> Hi Andreas,
>
> you have
>
> Field("date", 'date', unique = True)
>
> "date" is a
Hi Andreas,
you have
Field("date", 'date', unique = True)
"date" is a reserved keyword and cannot be the name of a field/
column.
Massimo
On Feb 1, 3:37 pm, baloan wrote:
> Hello,
>
> I'm using PostgreSQL. Changing db.py from
>
> db.define_table('position',
> Field("day", 'dat
42 matches
Mail list logo
