this is fixed for me in latest trunk!
On Mar 4, 8:51 pm, Throngly wrote:
> Thanks!
>
> I can confirm this is fixed in 1.76.3
>
> On Mar 3, 11:28 am, mdipierro wrote:
>
>
>
> > I think this is now fixed in trunk.
>
> > On Mar 3, 3:24 am, Throngly wrote:
>
> > > I also get this problem with code
Thanks!
I can confirm this is fixed in 1.76.3
On Mar 3, 11:28 am, mdipierro wrote:
> I think this is now fixed in trunk.
>
> On Mar 3, 3:24 am, Throngly wrote:
>
> > I also get this problem with code that used to work before the
> > ".count() to len()" change, so it appears to be a regression.
Thanks!
I can confirm this is fixed in 1.76.3
On Mar 3, 11:28 am, mdipierro wrote:
> I think this is now fixed in trunk.
>
> On Mar 3, 3:24 am, Throngly wrote:
>
> > I also get this problem with code that used to work before the
> > ".count() to len()" change, so it appears to be a regression.
I think this is now fixed in trunk.
On Mar 3, 3:24 am, Throngly wrote:
> I also get this problem with code that used to work before the
> ".count() to len()" change, so it appears to be a regression.
>
> My traceback is as follows:
>
> Traceback (most recent call last):
> File "/base/data/home/
I also get this problem with code that used to work before the
".count() to len()" change, so it appears to be a regression.
My traceback is as follows:
Traceback (most recent call last):
File "/base/data/home/apps/throngly-com/1.340262947933306301/gluon/
restricted.py", line 173, in restricted
Can you send me the complete traceback please. This is different than
the error that strasted the thread (about count()).
Massimo
On Mar 1, 5:24 am, Richard wrote:
> when using appadmin for gae to delete all records that satisfy the
> query "db.scrape.id>0" I get:
>
> Invalid Query
>
> object of
when using appadmin for gae to delete all records that satisfy the
query "db.scrape.id>0" I get:
Invalid Query
object of type 'Query' has no len()
I get this with both the latest release and trunk.
On Mar 1, 12:09 am, mdipierro wrote:
> they should be quivalent
>
> On Feb 23, 10:11 pm, Richa
they should be quivalent
On Feb 23, 10:11 pm, Richard wrote:
> I sometimes get that ID error on both GAE and the development server,
> and for non-delete operations such as:
>
> db(db.client.id > 0).select()
>
> so to be more robust I have replaced ID calls with:
>
> db().select(db.client.ALL)
>
On Feb 4, 12:16 pm, mdipierro wrote:
> do you use 2.5 or something else locally?
it would be because GAE uses 2.5:
http://code.google.com/appengine/docs/python/gettingstarted/devenvironment.html
--
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
I sometimes get that ID error on both GAE and the development server,
and for non-delete operations such as:
db(db.client.id > 0).select()
so to be more robust I have replaced ID calls with:
db().select(db.client.ALL)
On Feb 7, 11:33 am, Jon Romero wrote:
> the problem seems to happen when
For now I implemented your suggestion in trunk. Thanks what_ho.
Massimo
On Feb 21, 5:03 pm, what_ho wrote:
> I got the same issue, delete operations by id work locally, but not on
> gae (dev_appserver or live).
>
> Modifying from .count() to len(..) appears to fix this for me. I
> locally modifi
I will try fix but if I get a patch sooner it is better. Using len may
be slower than using count. there has to be a better solution.
-- Forwarded message --
From: Miguel Goncalves
Date: Feb 22, 7:28 pm
Subject: GAE delete() has subtle difference compared to native Web2Py
To: web
I am running into the same problem. Replacing count by len seems to work.
Will this fix be included in the next version of web2py or is there a
"better"/other way of addressing this?
-Miguel
On Sun, Feb 21, 2010 at 3:03 PM, what_ho wrote:
> I got the same issue, delete operations by id work
I got the same issue, delete operations by id work locally, but not on
gae (dev_appserver or live).
Modifying from .count() to len(..) appears to fix this for me. I
locally modified the delete method in gql.py, line 692 as follows:
def delete(self):
self._db['_lastsql'] = 'DELETE WHERE %
My traceback is as follows:
In FILE: /base/data/home/apps/throngly-com/1.339746990702093170/
applications/throngly/controllers/people.py
Traceback (most recent call last):
File "/base/data/home/apps/throngly-com/1.339746990702093170/gluon/
restricted.py", line 173, in restricted
exec ccode
What is the exact traceback?
On Feb 3, 6:11 pm, Carl wrote:
> This may be related to GAE update_record() has subtle difference
> compared to native
> Web2Pyhttp://groups.google.com/group/web2py/browse_thread/thread/a69afded01...
> but until shown otherwise, I've posed separately.
>
> I have this
Yes, I'm also seeing this problem. Does anyone have a workaround other
than querying by another field (which unfortunately isn't an option
for me)?
--
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To post to this group, send email to web...@googl
the problem seems to happen when you try to query by the id field and
then delete (I could delete when I chose a different field)
On Feb 7, 2:18 am, Jon Romero wrote:
> Some thing happens to me. When I do:
> db(db.table.id == some_id_that_exists).delete, I get the same count
> error
>
> On Feb 4,
Happens on gae dev environment and on the normal gae server.
On Feb 7, 2:18 am, Jon Romero wrote:
> Some thing happens to me. When I do:
> db(db.table.id == some_id_that_exists).delete, I get the same count
> error
>
> On Feb 4, 3:16 am, mdipierro wrote:
>
> > do you use 2.5 or something else lo
Some thing happens to me. When I do:
db(db.table.id == some_id_that_exists).delete, I get the same count
error
On Feb 4, 3:16 am, mdipierro wrote:
> do you use 2.5 or something else locally?
>
> On Feb 3, 6:11 pm, Carl wrote:
>
> > This may be related toGAEupdate_record() has subtle difference
>
do you use 2.5 or something else locally?
On Feb 3, 6:11 pm, Carl wrote:
> This may be related to GAE update_record() has subtle difference
> compared to native
> Web2Pyhttp://groups.google.com/group/web2py/browse_thread/thread/a69afded01...
> but until shown otherwise, I've posed separately.
>
21 matches
Mail list logo
