bummer, my fault. with trunk shell
q = db.auth_event.id 0
q = db.auth_event.time_stamp request.now
db(q)._select()
SELECT auth_event.id, auth_event.time_stamp, auth_event.client_ip,
auth_event.user_id, auth_event.origin, auth_event.description FROM
auth_event WHERE ((auth_event.id 0) AND
On Friday, April 26, 2013 12:57:39 AM UTC-4, Massimo Di Pierro wrote:
I do not think the problem is == but the data you are comparing (a date
with a string).
I don't think that's the problem:
q = db.auth_event.id 0
q = db.auth_event.time_stamp = '4/1/13'
q = db.auth_event.time_stamp =
Cliff, can you provide some table definitions and a full query that
reproduces the problem?
On Thursday, April 25, 2013 10:13:09 PM UTC-4, Cliff Kachinske wrote:
The = is working on other query clauses, just not the ones I said were
giving problems.
I'll get dal.py from trunk tomorrow AM
q = db.auth_event.time_stamp = '4/1/13'
should be
q = db.auth_event.time_stamp = '2013-01-04 00:00:00'
'4/1/13' is a string, not a date or datetime object nor something the
database can make sense of.
On Friday, 26 April 2013 06:02:31 UTC-5, Anthony wrote:
On Friday, April 26, 2013 12:57:39
I think I caused the problem. Yesterday morning I installed system updates
but I didn't reboot until this morning.
Now everything is working.
So I am both embarrassed and apologetic right now. Sorry for wasting
everybody's time.
Cliff Kachinske
On Friday, April 26, 2013 7:03:09 AM UTC-4,
On Friday, April 26, 2013 8:02:51 AM UTC-4, Massimo Di Pierro wrote:
q = db.auth_event.time_stamp = '4/1/13'
should be
q = db.auth_event.time_stamp = '2013-01-04 00:00:00'
Yes, my only point was that comparing a datetime field to a string (though
invalid in this case) doesn't produce the
Don't be. A false positive is always better than a bug unchecked. :-)
On Friday, 26 April 2013 07:18:42 UTC-5, Cliff Kachinske wrote:
I think I caused the problem. Yesterday morning I installed system
updates but I didn't reboot until this morning.
Now everything is working.
So I am
prepare a table model and a select() to reproduce the issue please...
PS: I'm not sure that = is recommended/supported.
--
---
You received this message because you are subscribed to the Google Groups
web2py-users group.
To unsubscribe from this group and stop receiving emails from it, send
= is now in trunk but one cannot do
query = date_field 4/1/13 and 4/5/13
On Thursday, 25 April 2013 13:16:52 UTC-5, Niphlod wrote:
prepare a table model and a select() to reproduce the issue please...
PS: I'm not sure that = is recommended/supported.
--
---
You received this message
On Thursday, April 25, 2013 7:11:17 PM UTC-4, Massimo Di Pierro wrote:
= is now in trunk but one cannot do
I think it's always been possible to do = with Query objects because the
__and__ method is defined. What was recently added was __rand__ and
__ror__, which according to
The = is working on other query clauses, just not the ones I said were
giving problems.
I'll get dal.py from trunk tomorrow AM and try it.
@Massimo, perhaps I wasn't clear. This query = date_field 4/1/13 and
4/5/13 stuff isn't what I wrote, it's what dal.py emitted.
On Thursday, April 25,
I do not think the problem is == but the data you are comparing (a date
with a string).
On Thursday, 25 April 2013 21:13:09 UTC-5, Cliff Kachinske wrote:
The = is working on other query clauses, just not the ones I said were
giving problems.
I'll get dal.py from trunk tomorrow AM and try
12 matches
Mail list logo
