Re: [web2py] query in DAL

[Vasile Ermicioi]

_sql1 = db(db.logs.date.year()==2010)._select(db.logs.date,
db.logs.item, groupby=db.logs.item)
rows = db(db.logs.item.belongs(_sql1) & (db.stock.item ==
db.logs.item)).select(db.logs.date,db.logs.item.count(),
groupby=db.logs.date)

notice _select for the first query

[web2py] Re: 2 quickies about cache

[Magnitus]

> web2py uses the query "db.log.id==X" as the key for the cache (where X
> will be replaced by the actual value).

Clever. Very simple, yet powerful.

Thanks for the clarification.

> The problem is that if you have a lot of records this may cause a
> memory leak since, in theory, you may be caching every individual
> record.

Well, maybe not memory leaks per say in the C++ sense of the terms
where memory is held up, yet no longer accessible, because pointers to
it not longer exist.

However, I get what you are saying that there is a danger that you get
unbound memory usage and I would theorize that the danger is greater
than just every DB record being held in memory.

If you have several result sets with some rows overlapping between
results (ie, in set terminology, the sets are not disjoint), couldn't
you have several times the number of records in the DB held up in
memory?

Obviously, you have to exert care and make sure that the possible sets
covered by the key sample space is manageable or and possibly use disk
cache (assuming that the disk cache is on a separate hard disk than
the DB), but that responsibility is incumbent on the end user rather
than the framework.

Obviously, the example I gave is not practical, but illustrates my
question well.

>
> On Jan 28, 3:52 pm, Magnitus  wrote:
>
> > I'm trying to determine whether the built-in web2py cache will fulfill
> > my needs or not and thus need a clarification on the following...
>
> > Based on this completely artificial example to illustrate my
> > questions:
>
> > someModule.py:
>
> > def ICacheLogs(cache, X):
> >     return db(db.log.id==X).select(db.log.ALL, cache=(cache.ram,
> > 3600))
>
> > default.py (controller):
>
> > from someModule import ICacheLogs
>
> > def f1():
> >      #Verify request.vars.X and whatnot
> >      logs = ICacheLogs(cache, int(request.vars.X))
> >      #Some more logic
>
> > def f2():
> >      #Verify request.vars.X and whatnot
> >      logs = ICacheLogs(cache, int(request.vars.X))
> >      #Some more logic
>
> > 1) If a user quickly accesses the f1 function with X set to 1 and then
> > again with X set to 2, will the logs result of second request be
> > cached on top of the logs result for first request (or worse, use the
> > cached result of the first request even though the parameters differ)
> > or will it know to cache them separately because they have different
> > parameters?
>
> > 2) If a user quickly accesses the f1 function with X set to 1 and then
> > accesses the f2 function with X set to 1 also, will the logs result in
> > f2 be taken from the cached result from the f1 call or will it be
> > cached again separately because the caching is performed from a
> > different function in the controller?
>
>

[web2py] Re: T-Shirts web2py

[mart]

just a thought... wouldn't an app, 'powered by web2py', where we go to
buy stuff (like t-shirts) take the cause further? and if making money
is the plan, should we not expand the product line to include other
frameworks; shows confidence, we can make more money for web2py AND,
we can use proven marketing tactics by involving the customer in the
marketing strategy... maybe with a slogan like:


 Web2py, Enterprise Framework

   'We support Django!'



It has 2 meanings :)



On Jan 28, 10:36 am, Robert  wrote:
> On 2011-01-27 17:03:21 -0500, mikech said:
>
> > +1
> > Zazzle is another alternative. �I don't know if you've ordered t-shirts
> > from Cafe Express, but I did some time ago, and they seemed very
> > lightweight. �Don't know if Zazzle is
> > any better. �
> > Here is a comparison:�
> >http://www.squidoo.com/cafepress_alternative
>
> Oh, yeah, I would like a thicker shirt.
>
> --
> Robert

[web2py] Re: PDF Reports with Pisa

[mart]

Oh, I'm sure the problem is on my side (I have tones of crap in my
web2py server). I'm sure if I clean up, things would run much
smoother... Actually, I think I will. Lemme install a fresh server
with basic app, and I'll try it. I'll let you know what I find.

For now, I can just say that I was unable to import the plugin,
because the exception stated that it could not find it (when the path
it displayed did match where I had installed it). The only diffence I
had with what you documented in your example was the names of the
controller and view.

ANyways, I'll let you know.

Mart :)

On Jan 28, 7:19 am, António Ramos  wrote:
> what about reportlab?
>
> 2011/1/28 Lucas D'Avila 
>
>
>
>
>
>
>
> > Can you be more specific? have any suggestions to improve this?
>
> > --
>
> > Lucas D'Avila
> >http://flavors.me/lucasdavila
> > Em 28/01/2011 05:46, "mart"  escreveu:
>
> > > Just letting you now... I looking to see it in action (the custom
> > > _code part looks really interesting), but am stumped as it tries to do
> > > the local import ... it doesn't seem to see the plugin
>
> > > On Jan 27, 4:30 am, mart  wrote:
> > >> This is nice stuff!
>
> > >> On Jan 26, 9:56 pm, "Lucas D'Avila"  wrote:
>
> > >> > Hi!
>
> > >> > I added support for Pisa [1] on appreport plugin [2], appreport now
> > has two
> > >> > engines to generate PDF documents: the pyfpdf and Pisa.
>
> > >> > Simply import the appreport plugin in web2py and use, no need to
> > install
> > >> > other dependent packages.
>
> > >> > --
>
> > >> > Download and documentation, visit the wiki [3], i also added in the
> > wiki, a
> > >> > new example about how to generate complex reports, rendering the
> > web2py
> > >> > views (taking advantage of the ease embedding python code in views).
>
> > >> > [1]http://www.xhtml2pdf.com/
> > >> > [2]https://github.com/lucasdavila/plugin-appreport
> > >> > [3]https://github.com/lucasdavila/plugin-appreport/wiki
>
> > >> > Hug!
>
> > >> > --
> > >> > Lucas D'Avilahttp://flavors.me/lucasdavila

[web2py] Re: django admin like app/plugin in web2py

[mart]

Hey this is nice! Makes it easy to create a group of admins! :)

Also, you can always make appAdmin open & available for your app to
all users (its trivial to do really), although i don't see any
benefit. hum come to think of it, its probably a bug. I like
Bruno's script better than handing the keys to everyone because you
can add filters and apply them to groups.


Mart :)


On Jan 28, 8:16 am, Bruno Rocha  wrote:
> I use something like this:
>
> 
> @auth.requires_membership('admin')
> def index():
>     args = request.args
>     title = 'Administration'
>     if not args:
>         link = UL(*[LI(A(tab,_href=URL(args=tab))) for tab in db.tables])
>         return dict(items=link,title=title)
>
>     if not args(1):
>         i = 0
>     else:
>         i =1
>
>     for tab in db.tables:
>         if tab==args(i):
>             tb = db[tab]
>
>     if args(0)=='edit':
>         form = crud.update(tb, args(2),next=URL(f='admin',args=args(1)))
>         items = None
>         titulo = 'Edit %s ' % args(i)
>     else:
>         form = crud.create(tb)
>         rows = db().select(tb.ALL)
>         items = SQLTABLE(rows,linkto='editar')
>         titulo = 'Insert %s ' % args(i)
>
>     return dict(form=form,items=items,title=title)
>
> 
>
> Bruno Rochahttp://about.me/rochacbruno/bio

[web2py] Re: Is there an alternative to Django's Pinax in the world of Web2py? Options

[Anthony]

Where is it?

[web2py] Re: Is there an alternative to Django's Pinax in the world of Web2py?

[William]

if somebody can use web2py to build a facebook like or groupon like site, 
that would beat django or pinax :)

i want to see web2py go to mainstream, it is so young!

-Bill

[web2py] Re: LIKE case sensitivity: Postgres differs to MySQL => DAL not portable

[KMax]

On 29 янв, 05:39, Bernd Rothert  wrote:
> On 28 Jan., 16:46, Thadeus Burgess  wrote:
>
> > Case sensitive search is one of the benefits of using postgres instead of
> > mysql!
>
> As Fran wrote case insensitive LIKE is just a default for MySQL and
> sqlite. MySQL supports case sensitive search:
This make .like() for mysql work not same as PG, etc...
>
> # SELECT * FROM person WHERE name LIKE BINARY '%Pi%';
>
> sqlite3's LIKE can be configured with "PRAGMA
> case_sensitive_like=yes".

Is't a way to add .ilike() for case insensitive select?
Anyway .like() for mysql should be adjusted to be case sensitive,
if .ilike() will be implemented.
Is'nt it?

Re: [web2py] Re: web2pyslices migration

[Bruno Rocha]

I created a twitter account for @web2pyslices

For now, it will only automatic tweet about reamdom slices, comments and
updates on the site, also it will tweet some random tips taken from here,
google search and from the official book.

Follow us http://twitter.com/web2pyslices (a better logo and avatar is on
the way)

Re: [web2py] Re: Adding fields to the default register form;

[Anthony]

On Friday, January 28, 2011 9:15:20 PM UTC-5, rochacbruno wrote: 
>
> 2011/1/28 Anthony 
>
>> Altering forms via server-side DOM manipulations should be documented in 
>> the book. It seems to come up a lot, but I don't think it's all that obvious 
>> or explicit in the book. The Views chapter (ch. 5) discusses HTML helpers 
>> and server-side DOM generally, but I don't think there's any discussion of 
>> using these methods specifically to customize forms (because FORM and 
>> SQLFORM are discussed in ch. 7, it's not immediately obvious that they are 
>> also HTML helper objects and can therefore be manipulated in the same way). 
>> Examples of this probably belong in the "Custom forms" section (
>> http://web2py.com/book/default/chapter/07#Custom-forms), or somewhere in 
>> ch. 7.
>>
>>
> Yes, the only place I see this is in chapter #5 
> http://web2py.com/book/default/chapter/05#Server-side-DOM-and-Parsing 
> I agree with you, and I think we need some explaination about using DOM to 
> forms manipulation.
>
> I dont know if there are any other caveats about it, I did not try the 
> validation but I think it should work very well.
>
 
Chapter 7 alludes to it in the intro but never follows up: 

"Arbitrary HTML code can be inserted into or extracted from the form using 
helpers."

There's also this slice: 
http://www.web2pyslices.com/main/slices/take_slice/43

Anthony

Re: [web2py] Re: Adding fields to the default register form;

[Bruno Rocha]

2011/1/28 Anthony 

> On Thursday, January 27, 2011 12:53:34 PM UTC-5, rochacbruno wrote:
>
>> *Manipulation of the SQLFORM object*
>>  {{=form.elements()[0].insert(0,LABEL('test:',INPUT(_type='text')))}}
>>  or in a more comprehensive way
>>  {{=form.elements('form tr td')[0].insert(0,INPUT())}}
>>
>
> Altering forms via server-side DOM manipulations should be documented in
> the book. It seems to come up a lot, but I don't think it's all that obvious
> or explicit in the book. The Views chapter (ch. 5) discusses HTML helpers
> and server-side DOM generally, but I don't think there's any discussion of
> using these methods specifically to customize forms (because FORM and
> SQLFORM are discussed in ch. 7, it's not immediately obvious that they are
> also HTML helper objects and can therefore be manipulated in the same way).
> Examples of this probably belong in the "Custom forms" section (
> http://web2py.com/book/default/chapter/07#Custom-forms), or somewhere in
> ch. 7.
>
>
Yes, the only place I see this is in chapter #5
http://web2py.com/book/default/chapter/05#Server-side-DOM-and-Parsing
I agree with you, and I think we need some explaination about using DOM to
forms manipulation.

I dont know if there are any other caveats about it, I did not try the
validation but I think it should work very well.

[web2py] Re: T-Shirts web2py

[Robert]

On 2011-01-27 17:03:21 -0500, mikech said:


+1
Zazzle is another alternative.  I don't know if you've ordered t-shirts 
from Cafe Express, but I did some time ago, and they seemed very 
lightweight.  Don't know if Zazzle is

any better.  
Here is a comparison: 
http://www.squidoo.com/cafepress_alternative



Oh, yeah, I would like a thicker shirt.

--
Robert

Re: [web2py] Re: Adding fields to the default register form;

[Anthony]

On Thursday, January 27, 2011 12:53:34 PM UTC-5, rochacbruno wrote: 
>
> *Manipulation of the SQLFORM object*
>  {{=form.elements()[0].insert(0,LABEL('test:',INPUT(_type='text')))}}
>  or in a more comprehensive way
>  {{=form.elements('form tr td')[0].insert(0,INPUT())}}
>
 
Altering forms via server-side DOM manipulations should be documented in the 
book. It seems to come up a lot, but I don't think it's all that obvious or 
explicit in the book. The Views chapter (ch. 5) discusses HTML helpers and 
server-side DOM generally, but I don't think there's any discussion of using 
these methods specifically to customize forms (because FORM and SQLFORM are 
discussed in ch. 7, it's not immediately obvious that they are also HTML 
helper objects and can therefore be manipulated in the same way). Examples 
of this probably belong in the "Custom forms" section (
http://web2py.com/book/default/chapter/07#Custom-forms), or somewhere in ch. 
7.
 
Anthony

[web2py] Re: Important Pycon 2011

[Anthony]

Massimo offered to reimburse $70 of the registration fee to the first 5 
people to sign up. I'm not sure if I'm in the first 5 (registered on Jan. 
16), but if I am, I offer my $70 reimbursement to whoever signs up next. : )
 
I hope they don't cancel it -- I'm looking forward to meeting some other 
web2py users in person.
 
See you in Atlanta.
 
Anthony
 

On Friday, January 28, 2011 4:20:18 PM UTC-5, Massimo Di Pierro wrote:

> The web2py Python tutorial has 8 registered participants. That is not 
> god enough. There is still a possibility it may be cancelled. 
>
> I am told web2py is easy and perhaps people do not need a tutorial but 
> I promise I will do my best to cover things you probably do not know 
> and make it worthwhile. 
>
> So if you are planning to attend PyCon 2011, I encourage to register 
> for the web2py tutorial "web2py secrets" and some of the other 
> excellent tutorials. 
>
> Massimo 
>

[web2py] Testing model validation

[blackthorne]

I'm looking for a hook in web2py that allows me to check if a model is
valid.

It doesn't have to work 100%, but "best-offer", kind of what we have
on the web editor right after saving the model file.

Is this possible to do for a given file?

Thank you,
Best regards

Re: [web2py] query in DAL

[beto (R3)]

Hey:

Nope.. that won't work.. that puts everything in a single query.. The
reason I'm doing SELECT ... FROM ( SELECT.. GROUP BY ..) is to get rid
of multiple items in the same day. That's why I group by date, items
and then group by date.

If I could do a count(distinct(items)) I could do that in a single query :(..

Hope I made my point..

thanks again!


On Fri, Jan 28, 2011 at 7:59 PM, Vasile Ermicioi  wrote:
> perhaps
> db((db.logs.date.year()==2010) & (db.stock.item ==
> db.logs.item)).select(db.logs.date,db.logs.item.count(),
> groupby=db.logs.date)

[web2py] Re: Fwd: web2py basic auth

[Niphlod]

call_or_redirect() is the real "addition" here  you can use both a
URL or a function to manage on_failed_authentication and
on_failed_authorization ... take a look in gluon/utils.py

On Jan 28, 1:48 am, miguel  wrote:
> I suppose this is mentioned in the Change Log by:
> "on_failed_authorization can be a function, thanks Niphold"
>
> How is this used? could the function be a lambda, does it take params,
> is it an action (i.e. a controller function)?
>
> Also, is it possible to allow the usual login redirection in case it
> is not a service call? I'm thinking in these lines:
>
> def theFunction():
>     if request.function == 'call':
>         # return case forservice call
>     else:
>         # redirect to login form
>
> This would be useful for publishing the same service both for browsers
> and for other apps, like it is mentioned in 
> p://www.web2pyslices.com/main/slices/take_slice/48
> (see "Authentication"). This solution would also be useful for other
> non-browser-based clients. Would it work? How is the function used?
>
> Txs,
> Miguel
>
> -- Forwarded message --
> From: mdipierro 
> Date: Sep 23 2010, 2:34 pm
> Subject: web2py basic auth
> To: web2py-users
>
> Against trunk please. It is ok if you just send me a replacement file.
> I will diff and study it.
>
> On Sep 23, 8:52 am, Niphlod  wrote:
>
> > Never done a patch before, but I think in the night (here are 3PM) I
> > can manage to have a first draft.
>
> > I'd have to test it out, but for the beginning .. What wuold be the
> > patch against ? tools.py in trunk or tools.py in 1.85.3?
>
> > On 23 Set, 14:52, mdipierro  wrote:
>
> > > You are right. That would be best. Want to send me a patch?
>
> > > On Sep 23, 2:26 am, Niphlod  wrote:
>
>

[web2py] Re: LIKE case sensitivity: Postgres differs to MySQL => DAL not portable

[Bernd Rothert]

On 28 Jan., 16:46, Thadeus Burgess  wrote:
> Case sensitive search is one of the benefits of using postgres instead of
> mysql!
>

As Fran wrote case insensitive LIKE is just a default for MySQL and
sqlite. MySQL supports case sensitive search:

# SELECT * FROM person WHERE name LIKE BINARY '%Pi%';

sqlite3's LIKE can be configured with "PRAGMA
case_sensitive_like=yes".

[web2py] Re: Learning materials for newbie

[mikech]

I've also found it pretty useful recently to run the web2py app from source 
in a good ide, in my case WingIDE which I have a 10 day trial on, and step 
thru the program using the debugger.  

Re: [web2py] query in DAL

[Vasile Ermicioi]

perhaps
db((db.logs.date.year()==2010) & (db.stock.item ==
db.logs.item)).select(db.logs.date,db.logs.item.count(),
groupby=db.logs.date)

[web2py] Re: Learning materials for newbie

[Anthony]

On Friday, January 28, 2011 5:41:11 PM UTC-5, noob.py wrote: 
>
> Thanks for quick answer. 
> But let's assume that I know Python, web2py, HTML, CSS, JavaScript (I 
> suppose I must learn'em all, right?). Do I have to learn something 
> more? Or such knowledge is sufficient for web apps developement?

 
All that stuff will probably get you going pretty well. You will need to run 
your apps somewhere, so you could also learn a bit about hosting and 
deployment (e.g., Linux, Apache, etc.). The web2py book actually covers some 
of that, and there are some scripts to ease the setup. The web2py book also 
covers deployment on Google App Engine. You could also learn about databases 
and data modeling, but for simpler apps, your knowledge probably doesn't 
have to be too deep there.
 
Anthony

Re: [web2py] Re: LIKE case sensitivity: Postgres differs to MySQL => DAL not portable

[Thadeus Burgess]

IMHO This breaks backwards compatibility...

--
Thadeus




On Sat, Jan 29, 2011 at 6:31 AM, Massimo Di Pierro <
massimo.dipie...@gmail.com> wrote:

> I treat this as a bug fix.
>
> On Jan 28, 12:52 pm, Anthony  wrote:
> > On Friday, January 28, 2011 12:58:30 PM UTC-5, Massimo Di Pierro wrote:
> >
> > > We need two steps:
> >
> > > 1) make it behave the same (which means case insensitive, ilike on
> > > postgresql, now in trunk)
> >
> > Doesn't this change break backward compatibility, or are you treating
> this
> > as a bug fix?
> >
> > > 2) yes we can add a case_sensitive arg that defaults to True (not done
> > > yet but I would take a patch).
> >
> > If we do want to maintain backward compatibility, wouldn't the new case
> arg
> > have to default to something like "let the RDBMS decide" -- it couldn't
> just
> > default to True (or False) because different databases have different
> > defaults, no? On the other hand, if that's not a concern, do we want
> > case_sensitive to default to True -- it sounds like not all databases
> even
> > offer that option?
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > > On Jan 28, 11:37 am, Anthony  wrote:
> > > > What if like() had something like a 'case' argument, with three
> possible
> > > > values: sensitive, insensitive, and rdbms_default (defaulting to
> > > > rdbms_default)?
> >
> > > > We obviously need to maintain backward compatibility, but like() is a
> > > web2py
> > > > operator, not a specific RDBMS operator, so it would be nice if
> there's
> > > any
> > > > easy way to make sure like() calls are as portable as possible
> without
> > > > requiring code changes.
> >
> > > > Anthony
>

[web2py] Re: Learning materials for newbie

[noob.py]

THANKS GUYS!

[web2py] Re: Learning materials for newbie

[noob.py]

Thanks for quick answer.
But let's assume that I know Python, web2py, HTML, CSS, JavaScript (I
suppose I must learn'em all, right?). Do I have to learn something
more? Or such knowledge is sufficient for web apps developement?

[web2py] Re: empty list:reference seems like a bug

[Massimo Di Pierro]

Can you please try trunk?

On Jan 28, 3:47 pm, LightOfMooN  wrote:
> Running 1.91.6 too.
>
> db.define_table('tag',
>     Field('name', 'string'), format='%(name)s')
>
> db.define_table('rolic',
>     Field('name', 'string'),
>     Field('tags', 'list:reference tag', required=True),
>     )
>
> Add 1 rolic with empty tags, and "database administration -> db.rolic"
> goes to error:
> ProgrammingError: syntax error at or near ")"
> LINE 1: SELECT  tag.id FROM tag WHERE (tag.id IN ());
>
> ERROR SNAPSHOT
> (syntax error at or near ")"
> LINE 1: SELECT  tag.id FROM tag WHERE (tag.id IN ());
>                                                   ^
> )
>
> On 29 янв, 00:09, DenesL  wrote:
>
>
>
>
>
>
>
> > I have a table with empty list:reference fields and db admin does not
> > have a problem with it.
> > Running 1.91.6 .
>
> > On Jan 28, 10:12 am, LightOfMooN  wrote:
>
> > > It's a problem, that if i have empty list:reference, the standard
> > > database administration don't work because of wrong query:
>
> > > Traceback (most recent call last):
> > >   File "/home/www-data/web2py/gluon/restricted.py", line 188, in
> > > restricted
> > >     exec ccode in environment
> > >   File "/home/www-data/web2py/applications/funportal/views/
> > > appadmin.html", line 191, in 
> > >     
> > >   File "/home/www-data/web2py/gluon/sqlhtml.py", line 1349, in
> > > __init__
> > >     r = field.represent(r)
> > >   File "/home/www-data/web2py/gluon/dal.py", line 3113, in
> > > list_ref_repr
> > >     refs = r._db(r.id.belongs(ids)).select(r.id)
> > >   File "/home/www-data/web2py/gluon/dal.py", line 4507, in select
> > >     return self.db._adapter.select(self.query,fields,attributes)
> > >   File "/home/www-data/web2py/gluon/dal.py", line 1003, in select
> > >     rows = response(sql)
> > >   File "/home/www-data/web2py/gluon/dal.py", line 994, in response
> > >     self.execute(sql)
> > >   File "/home/www-data/web2py/gluon/dal.py", line 1067, in execute
> > >     return self.log_execute(*a, **b)
> > >   File "/home/www-data/web2py/gluon/dal.py", line 1064, in log_execute
> > >     return self.cursor.execute(*a,**b)
> > > ProgrammingError: syntax error at or near ")"
> > > LINE 1: SELECT  tag.id FROM tag WHERE (tag.id IN ());

[web2py] Re: 2 quickies about cache

[Massimo Di Pierro]

web2py uses the query "db.log.id==X" as the key for the cache (where X
will be replaced by the actual value).
The problem is that if you have a lot of records this may cause a
memory leak since, in theory, you may be caching every individual
record.

On Jan 28, 3:52 pm, Magnitus  wrote:
> I'm trying to determine whether the built-in web2py cache will fulfill
> my needs or not and thus need a clarification on the following...
>
> Based on this completely artificial example to illustrate my
> questions:
>
> someModule.py:
>
> def ICacheLogs(cache, X):
>     return db(db.log.id==X).select(db.log.ALL, cache=(cache.ram,
> 3600))
>
> default.py (controller):
>
> from someModule import ICacheLogs
>
> def f1():
>      #Verify request.vars.X and whatnot
>      logs = ICacheLogs(cache, int(request.vars.X))
>      #Some more logic
>
> def f2():
>      #Verify request.vars.X and whatnot
>      logs = ICacheLogs(cache, int(request.vars.X))
>      #Some more logic
>
> 1) If a user quickly accesses the f1 function with X set to 1 and then
> again with X set to 2, will the logs result of second request be
> cached on top of the logs result for first request (or worse, use the
> cached result of the first request even though the parameters differ)
> or will it know to cache them separately because they have different
> parameters?
>
> 2) If a user quickly accesses the f1 function with X set to 1 and then
> accesses the f2 function with X set to 1 also, will the logs result in
> f2 be taken from the cached result from the f1 call or will it be
> cached again separately because the caching is performed from a
> different function in the controller?

Re: [web2py] query in DAL

[beto (R3)]

Hey Vasile:

Thanks for your answer.. yes.. that I know and that's actually what
I'm doing.. but I'd like to use the benefits of doing it with DAL.
(cache the queries, security validation for parameters, etc).

regards.

On Fri, Jan 28, 2011 at 7:18 PM, Vasile Ermicioi  wrote:
> you always can execute sql
> sql_str =  'SELECT * FROM ...'
> rows = db.executesql(sql_str)
> but your results will not be objects, but an array of arrays or an array of
> dicts if you do
> sql_str = '''SELECT   date, count(foo.items) as total ... '
> rows = db.executesql(sql_str, as_dict = True)
> for row in rows:
>     print row['date'], row['total']

[web2py] Re: Is there an alternative to Django's Pinax in the world of Web2py?

[Massimo Di Pierro]

The pinax web site says:

...including apps for:

account management [x]
openid [x]
e-mail verification [?]
password management [x]
profiles [x]
notifications [z]
activity streams [z]
private betas / waiting lists [?]
badges [?]
tagging [t]
wikis [t]
forums [f]
blogs [t]
task tracking [?]
friend and follower relations [?]
and more...

x means the functionality is already in web2py code
z means also in web2py core using comet_messaging.py
t means provided by plugin_wiki
? means I am not sure because I do not know very well what Pinax does.


On Jan 28, 3:15 pm, pbreit  wrote:
> PInax looks really cool and helpful. I'm not aware of anything besides
> plugins and appliances.

[web2py] Re: web2py and gae : Delete everything in the datastore

[howesc]

if i remember correctly the bulk delete was google's christmas present to us 
- in the decemeber release, so it's a new feature, but quite handy!

[web2py] Re: LIKE case sensitivity: Postgres differs to MySQL => DAL not portable

[Massimo Di Pierro]

I treat this as a bug fix.

On Jan 28, 12:52 pm, Anthony  wrote:
> On Friday, January 28, 2011 12:58:30 PM UTC-5, Massimo Di Pierro wrote:
>
> > We need two steps:
>
> > 1) make it behave the same (which means case insensitive, ilike on
> > postgresql, now in trunk)
>
> Doesn't this change break backward compatibility, or are you treating this
> as a bug fix?
>
> > 2) yes we can add a case_sensitive arg that defaults to True (not done
> > yet but I would take a patch).
>
> If we do want to maintain backward compatibility, wouldn't the new case arg
> have to default to something like "let the RDBMS decide" -- it couldn't just
> default to True (or False) because different databases have different
> defaults, no? On the other hand, if that's not a concern, do we want
> case_sensitive to default to True -- it sounds like not all databases even
> offer that option?
>
>
>
>
>
>
>
>
>
> > On Jan 28, 11:37 am, Anthony  wrote:
> > > What if like() had something like a 'case' argument, with three possible
> > > values: sensitive, insensitive, and rdbms_default (defaulting to
> > > rdbms_default)?
>
> > > We obviously need to maintain backward compatibility, but like() is a
> > web2py
> > > operator, not a specific RDBMS operator, so it would be nice if there's
> > any
> > > easy way to make sure like() calls are as portable as possible without
> > > requiring code changes.
>
> > > Anthony

Re: [web2py] Learning materials for newbie

[Miguel Lopes]

Hi,

To learn Python I found these very helpful (no particular order):

   - Hetland's stuff is concise and clear which is not always the case :-)
  - http://hetland.org/writing/instant-hacking.html
  - http://hetland.org/writing/instant-python.html
   - Alan Gaud's on-line is also very clear and more detailed:
  - http://www.freenetpages.co.uk/hp/alan.gauld/tutor2/index.htm
   - Allen Downey's free book is also a good resource for the complete
   newbye (both online and as a free downloadable pdf):
  - http://www.greenteapress.com/thinkpython/thinkpython.html
   - tutor python list may also be helpful at times:
  - http://mail.python.org/mailman/listinfo/tutor

Regarding Python these resources are way more than enough to get by
developing web2py app's. For example although knowing about classes is
helpful to achieve some advanced stuff in web2py, you don't really need it
to accomplish great websites!

As for web2py you have already found the main resources: the book and this
list.
Sooner or later you get the urge to learn about jQuery or someother
javascript library. My advice is delay learning these as long as you can -
it's not a good idea to try to learn everything at once. On this note. Spend
a few days just playing with Python before you pick up web2py, this will
make web2py much simpler to learn. Following Alan Gauld's tut do the basics,
then the advanced (ignore the part about GUI programming - that's desktop).

You also have to pick some basic html to start with. For me learning html on
a need to know basis worked out fine.

Remember to google, google, then ask on the net/list(s)
Happy coding
HTH,
Miguel

On Fri, Jan 28, 2011 at 9:46 PM, Richard Vézina  wrote:

> Web2py book : http://www.web2py.com/book
>
> Richard
>
>
> On Fri, Jan 28, 2011 at 4:38 PM, noob.py  wrote:
>
>> Hello,
>> I'm totally new to programming, but very motivated to learn it. I'm
>> especially interested in creating web application (that's why I post
>> here). So, can anyone tell me what do I have to learn (except Python
>> and web2py of course) and point me some good learning materials and
>> resources (books, ebooks, web tutorials, etc.)?
>
>
>

[web2py] Re: LIKE case sensitivity: Postgres differs to MySQL => DAL not portable

[Massimo Di Pierro]

ILIKE is not the same as containing. It is a case insensitive LIKE

On Jan 28, 12:23 pm, villas  wrote:
> I suppose 'ilike' in PostgreSQL is similar to 'containing' in Firebird
> (except you don't use wildcards in FB).
>
> On Jan 28, 5:58 pm, Massimo Di Pierro 
> wrote:
>
>
>
>
>
>
>
> > We need two steps:
>
> > 1) make it behave the same (which means case insensitive, ilike on
> > postgresql, now in trunk)
> > 2) yes we can add a case_sensitive arg that defaults to True (not done
> > yet but I would take a patch).
>
> > On Jan 28, 11:37 am, Anthony  wrote:
>
> > > What if like() had something like a 'case' argument, with three possible
> > > values: sensitive, insensitive, and rdbms_default (defaulting to
> > > rdbms_default)?
>
> > > We obviously need to maintain backward compatibility, but like() is a 
> > > web2py
> > > operator, not a specific RDBMS operator, so it would be nice if there's 
> > > any
> > > easy way to make sure like() calls are as portable as possible without
> > > requiring code changes.
>
> > > Anthony
>
> > > On Friday, January 28, 2011 11:43:58 AM UTC-5, VP wrote:
> > > > I agree with Thadeus here that "like" should be what it means in each
> > > > case.  Changing the default meaning of "like" in each RDBMS will cause
> > > > confusion.   "ilike" can be a web2py thing, but "like" should be
> > > > specific to each RDMS.
>
> > > > On Jan 28, 9:46 am, Thadeus Burgess  wrote:
> > > > > I disagree! Your playing with things that shouldn't be played with.
>
> > > > > Not to mention that now you have just broken some of my apps that 
> > > > > perform
>
> > > > > case-sensitive queries in postgres this is just plain wrong in so
> > > > many
> > > > > ways.
>
> > > > > Add a new identifier to DAL... give me
>
> > > > > db(db.table.name.like('%printer%'))
>
> > > > > and then for case insensitive
>
> > > > > db(db.table.name.ilike('%printer%')).
>
> > > > > like would perform the actual operation that would happen from the 
> > > > > RDBMS,
>
> > > > > and ilike can be a web2py playing god version that makes sure all 
> > > > > rdbmses
>
> > > > > act the same.
>
> > > > > Case sensitive search is one of the benefits of using postgres 
> > > > > instead of
>
> > > > > mysql!
>
> > > > > --
> > > > > Thadeus
>
> > > > > On Fri, Jan 28, 2011 at 8:40 AM, Massimo Di Pierro <
>
> > > > > massimo@gmail.com> wrote:
> > > > > > I agree the behavior should be uniform. The easiest way is to make 
> > > > > > the
> > > > > > LIKE always case insensitive. I am patching trunk to use ILIKE with
> > > > > > postgresql.
>
> > > > > > On Jan 28, 3:01 am, KMax  wrote:
> > > > > > > On 7 дек 2010, 00:31, Fran  wrote:
>
> > > > > > > > - minimally it should be in a FAQ (ideally in the next Book) &
> > > > ideally
> > > > > > > > we could have a case_sensitive=True option for the DAL like()
> > > > > > > > operator...to ensure that both pgsql & mysql/sqlite existing 
> > > > > > > > apps
> > > > > > > > didn't break, it could default differently depending on the db
> > > > type?
>
> > > > > > > +1 vote
> > > > > > > sqlite has some issue with not ascii chars compare, but work in
> > > > > > > progress
> > > > > > > pgsql has ilike which works like mysql like (fix me)
>
> > > > > > > I' just patch dal to use ilike in .like() query for postgres, but 
> > > > > > > it
> > > > > > > more cheat then solution.

[web2py] Re: Bugfix for full CRUD internal read links

[Massimo Di Pierro]

oops. Thanks

On Jan 28, 12:33 pm, Bernd Rothert  wrote:
> The book's example for "full CRUD"
>
> def data(): return (form=crud())
>
> doesn't set the proper links from
>
> .../data/select/         to
> .../data/read//
>
> they instead go to
> .../read//
>
> This patch fixes the issue:
>
> --- a/gluon/tools.py    Fri Jan 28 09:54:47 2011 -0600
> +++ b/gluon/tools.py    Fri Jan 28 19:27:06 2011 +0100
> @@ -2668,7 +2668,7 @@
>          elif args[0] == 'create':
>              return self.create(args(1))
>          elif args[0] == 'select':
> -            return self.select(args(1),linkto=self.url('read'))
> +            return self.select(args(1),linkto=self.url(args='read'))
>          elif args[0] == 'read':
>              return self.read(args(1), args(2))
>          elif args[0] == 'update':

Re: [web2py] Speeding up IS_IN_DB

[howesc]

in places where i wanted to keep the dropdown, but not the overhead of 
creating a huge list, i filtered the list.  I was lucky enough that not all 
of the options were valid in all tables, and so i modified my IS_IN_DB() 
calls to return a much smaller filtered set of data.  not sure if this will 
work for you, but it's an idea.

christian

[web2py] Re: web2py and gae : Delete everything in the datastore

[devGS]

Did you try to do it through the dashboard? At Data, Datastore Admin
you have the option to select all of the entities and delete them.

On Jan 28, 10:56 pm, Nathan VanHoudnos  wrote:
> Thanks for the reply.
>
> To clarify, I want to wipe everything in the production datastore on
> Google's servers. If it were only as easy as clearing the development
> datastore!
>
> Cheers,
>
> Nathan
>
>
>
>
>
>
>
>
>
> On Fri, Jan 28, 2011 at 3:10 PM, devGS  wrote:
> > Run your web2py app with a command from your GAE library and the flag -
> > c.
> > i.e: dev_appserver.py -c C:\web2py
>
> > On Jan 28, 9:31 pm, Nathan VanHoudnos  wrote:
> > > Hi,
>
> > > I'm running web2py 1.91.6 on google app engine. I'd like to delete
> > > everything in the datastore and start over.
>
> > > If you have a quick solution for this, stop reading now and just tell me
> > the
> > > "web2py" way. :)
>
> > > There is a StackOverflow thread that I found:
>
> > >http://stackoverflow.com/questions/1062540/how-to-delete-all-datastor...
>
> > > which assumes that you setup everything in Models.py which uses syntax
> > very
> > > different from the DAL and I can't make heads or tails of it.
>
> > > I tried using the remote_api to do the deletion:
>
> > > vanhoudn@gauze:~/workspace/creatia-rubrics/src$ python2.5
> > > ~/google_appengine/remote_api_shell.py creatia-rubrics
> > > App Engine remote_api shell
> > > Python 2.5.5 (r255:77872, Sep 14 2010, 17:16:34)
> > > [GCC 4.4.3]
> > > The db, users, urlfetch, and memcache modules are imported.
> > > creatia-rubrics> from google.appengine.ext.db import GqlQuery
> > > creatia-rubrics> query = GqlQuery("SELECT * FROM allRatings")
> > > Traceback (most recent call last):
> > >   File "", line 1, in 
> > >   File
>
> > "/home/vanhoudn/google_appengine.1.4.1/google/appengine/ext/db/__init__.py"
> > ,
> > > line 2296, in __init__
> > >     model_class = class_for_kind(self._proto_query._entity)
> > >   File
>
> > "/home/vanhoudn/google_appengine.1.4.1/google/appengine/ext/db/__init__.py"
> > ,
> > > line 266, in class_for_kind
> > >     raise KindError('No implementation for kind \'%s\'' % kind)
> > > KindError: No implementation for kind 'allRatings'
>
> > > But it gives me this weird KindError. Before i can get to the
>
> > > db.delete(query)
>
> > > step. So how do you access the kinds that you create in models/db.py? I
> > > copied the GQL statement straight from the datastore viewer on
> > > appspot.comso it shouldn't be a syntax error.
>
> > > The relevant section of my models/db.py is:
>
> > > db.define_table('allRatings',
> > >                 Field('timeend','datetime',requires= IS_NOT_EMPTY() ),
> > >                 Field('timestart','datetime',requires= IS_NOT_EMPTY() ),
> > >                 Field('assignmentId',requires= IS_NOT_EMPTY() ),
> > >                 Field('experimentId',requires= IS_NOT_EMPTY() ),
> > >                 Field('workerId',requires= IS_NOT_EMPTY() ),
> > >                 Field('studentIds',requires= IS_NOT_EMPTY() ),
> > >                 Field('rubricCode',requires= IS_NOT_EMPTY() ),
> > >                 Field('ipaddress' ,default=request.client),
> > >                 Field('comment',requires= IS_NOT_EMPTY() ),
> > >                 Field('rawAnswers',requires= IS_NOT_EMPTY() ),
> > >                 Field('subscores',requires= IS_NOT_EMPTY() )
> > >                 )
>
> > > Any help would be appreciated!
>
> > > Cheers,
> > > --
> > > Nathan VanHoudnos
> > > |- Statistics & Public Policy PhD student
> > > |- Program for Interdisciplinary Education Research (PIER) Fellowship
> > > |- Carnegie Mellon University
> > > |-http://www.andrew.cmu.edu/user/nmv
>
> > > "Neglect of mathematics works injury to all knowledge,
> > >  since he who is ignorant of it cannot know the other
> > >  sciences or the things of this world." -- Roger Bacon
>
> --
> Nathan VanHoudnos
> |- Statistics & Public Policy PhD student
> |- Program for Interdisciplinary Education Research (PIER) Fellowship
> |- Carnegie Mellon University
> |-http://www.andrew.cmu.edu/user/nmv
>
> "Neglect of mathematics works injury to all knowledge,
>  since he who is ignorant of it cannot know the other
>  sciences or the things of this world." -- Roger Bacon

[web2py] Re: Speeding up IS_IN_DB

[Massimo Di Pierro]

Are you suggesting we change the way the default is assigned? If so..
let's duscuss this inw eb2py-developers because it is a complex
matter.

Massimo

On Jan 28, 12:16 pm, DenesL  wrote:
> list:reference fields get an IS_IN_DB validator if no explicit
> requires is defined.
> Note: the assigned requires is not a list.
>
> On Jan 28, 12:54 pm, Massimo Di Pierro 
> wrote:
>
>
>
>
>
>
>
> > Something else is wrong. If you have requires=[...] it should not
> > query the db for the possible references and it should not make the
> > dropdown.
>
> > Can we see the entire model?
>
> > Massimo
>
> > On Jan 28, 10:01 am, Johann Spies  wrote:
>
> > > On 28 January 2011 16:45, Massimo Di Pierro 
> > > wrote:
>
> > > > This:
>
> > > > requires = IS_IN_DB(db, db.joernaal.id, '%(titel)s')
>
> > > > indicates you want to a select/options dropbox and it takes time to
> > > > populate it.
>
> > > > Use instead:
>
> > > > requires = [IS_IN_DB(db, db.joernaal.id,'%(titel)s')]
>
> > > > so no dropbox and use autocomplete.
>
> > > Thanks for the suggestion which is an improvement but it did not make a
> > > difference in the speed.  The form still takes about 70 seconds to show 
> > > up.
> > > I suspect the list_references may be the culprit.  Maybe I must redisign 
> > > the
> > > database structure to handle 1 to many relationships differently.
>
> > > Regards
> > > Johann
> > > --
> > >  May grace and peace be yours in abundance through the full knowledge of 
> > > God
> > > and of Jesus our Lord!  His divine power has given us everything we need 
> > > for
> > > life and godliness through the full knowledge of the one who called us by
> > > his own glory and excellence.
> > >                                                     2 Pet. 1:2b,3a

[web2py] Re: Learning materials for newbie

[Anthony]

On Friday, January 28, 2011 4:38:39 PM UTC-5, noob.py wrote: 
>
> Hello, 
> I'm totally new to programming, but very motivated to learn it. I'm 
> especially interested in creating web application (that's why I post 
> here). So, can anyone tell me what do I have to learn (except Python 
> and web2py of course) and point me some good learning materials and 
> resources (books, ebooks, web tutorials, etc.)?

 
Welcome.
 
Specifically for programming web2py apps, the web2py book (
http://www.web2py.com/book) will take you a long way all by itself. It even 
includes a whole chapter on Python and covers some client-side stuff like 
jQuery. Also look at:

   - Examples: http://web2py.com/examples/default/examples 
   - web2py Slices: http://web2pyslices.com/main/default/index (currently 
   being revamped -- stay tuned) 
   - FAQ: http://www.web2py.com/AlterEgo (some items are outdated) 
   - Source code documentation: 
   http://www.web2py.com/examples/static/epydoc/index.html 
   - Source code: http://code.google.com/p/web2py/source/browse/

There are lots of great online resources for learning Python: 
http://wiki.python.org/moin/BeginnersGuide
 
For general web development tutorials, check out http://www.w3schools.com. 
It covers HTML, CSS, XML, Javascript, Ajax, jQuery, SQL, etc. You can even 
experiment with your own code right in the browser. Another good site is 
http://www.webmonkey.com/tutorials/.
 
For web2py questions, definitely ask here. For other programming questions, 
try http://stackoverflow.com/. There are also several subreddits that might 
be of interest to you:

   - http://www.reddit.com/r/Python 
   - http://www.reddit.com/r/learnpython 
   - http://www.reddit.com/r/programming/ 
   - http://www.reddit.com/r/learnprogramming

Hope that helps.
 
Anthony
 

[web2py] Re: GAE belongs (how to map long list)

[howesc]

I use belong on GAE quite frequently these days.  Arun - you found an 
outdated post. :(

christian

Re: [web2py] Learning materials for newbie

[Vasile Ermicioi]

>
> Web2py book : http://www.web2py.com/book


+ http://w3schools.com/

[web2py] Re: Disabling the error page in production.

[Nico de Groot]

You can use routes.py in the root of your web2py tree to reroute 404
and/or 400 errors to a more friendly page, see
http://web2py.com/book/default/chapter/04#Routes-on-Error

Nico

On 28 jan, 21:00, "David J."  wrote:
> How do I disable the error page in production?
>
> I would ideally like to replace it with a Nicer page same for 404 errors;
>
> I searched the book for error page; but I must have missed the part
> where it says disabling.
>
> Thanks.

Re: [web2py] Re: The web of connected p2p web2py apps ? (or a new kind of social network)

[Alexandre Andrade]

Please, Sqlite is not NOSQL, but a small, portable rdbms





2011/1/28 William 

> I don't know why people are constantly talking about the NOSQL hype.
> why bother them?
> Sqlite is included in web2py.
>
> I would rather to see a user admin which is better than django's.
>
> -Bill
>



-- 
Atenciosamente


Alexandre Andrade
Hipercenter.com Classificados Gratuitos e Inteligentes

Re: [web2py] query in DAL

[Vasile Ermicioi]

you always can execute sql

sql_str =  'SELECT * FROM ...'
rows = db.executesql(sql_str)

but your results will not be objects, but an array of arrays or an array of
dicts if you do

sql_str = '''SELECT   date, count(foo.items) as total ... '
rows = db.executesql(sql_str, as_dict = True)
for row in rows:
print row['date'], row['total']

[web2py] Re: Can any help me with new dal in trunk?

[DenesL]

Are you sure it worked before?
As far as I know mysql is not supported for legacy DBs using
primarykey.


On Jan 28, 5:04 pm, drayco  wrote:
> Hi, I updated my trunk version
>
> However, The same issue is still
>
> This is the new traceback
>
> Traceback (most recent call last):
>   File "/home/drayco/web2py/gluon/restricted.py", line 188, in
> restricted
>     exec ccode in environment
>   File "/home/drayco/web2py/applications/iscada/models/cfedb.py", line
> 16, in 
>     migrate = False)
>   File "/home/drayco/web2py/gluon/dal.py", line 3471, in define_table
>     sequence_name=sequence_name))
>   File "/home/drayco/web2py/gluon/dal.py", line 3755, in __init__
>     "primarykey must be a list of fields from table '%s " % tablename
> SyntaxError: primarykey must be a list of fields from table
> 'med_dnpmst_4
>
> SnapShot
>
> (primarykey must be a list of fields
> from table 'med_dnpmst_4 )
>
> File /home/drayco/web2py/gluon/dal.py in __init__ at line 3755
>
> Function argument list
>
> (self= }>, db= sql_mode='NO_BACKSLASH_ES...tables': [], '_migrate': True,
> '_pool_size': 10}>, tablename='med_dnpmst_4',
> *fields=[, ,
> , ,  object>, , ],
> **args={'primarykey': ['DireccionUTR', 'Indice'], 'sequence_name':
> None, 'trigger_name': None})
>
> Code listing
>
> 3750.
> 3751.
> 3752.
> 3753.
> 3754.
> 3755.
>
> 3756.
> 3757.
> 3758.
> 3759.
>
>         if hasattr(self,'_primarykey'):
>             for k in self._primarykey:
>                 if k not in self.fields:
>                     raise SyntaxError, \
> "primarykey must be a list of fields from table '%s " % tablename
>
>                 else:
>                     self[k].notnull = True
>
> On Jan 28, 8:35 am, Massimo Di Pierro 
> wrote:
>
> > this should now be fixed in trunk
>
> > On Jan 8, 2:58 pm, Thadeus Burgess  wrote:
>
> > >  All I know is that tables are issued as lowercase, but you can still 
> > > access
> > > your table as an uppercase attribute.
>
> > > There is an inconsistency in the DAL somewhere because of this... 
> > > Somewhere
> > > it is forgetting to convert to lower case. I don't know why converting 
> > > table
> > > names to lower case is forced in web2py and I disagree with it.
>
> > > for example:
>
> > > db = DAL()
> > > db.define_table('TableA', Field('Superman'))
> > > # CREATE TABLE tablea WITH FIELDS superman
> > > db(db.TableA.Superman == "clark").select().first().Superman
> > > # SELECT * FROM tablea WHERE superman="clark"
>
> > > --
> > > Thadeus
>
> > > On Sat, Jan 8, 2011 at 1:17 AM, mart  wrote:
> > > > really? I didn't know, thanks for pointing that out...
>
> > > > just out of curiosity
>
> > > > in
>
> > > > in __getitem__
> > > >    return dict.__getitem__(self, str(key))
> > > > KeyError: 'tecnogradua'
>
> > > > don't the attribute lookups get done by python ultimately?  Just
> > > > trying to understand...
> > > > how could this have worked if doing x.__getitem__ ? Even if dal does a
> > > > string.lower() or something, once the table is named and created,
> > > > would something (outside of migrate) not catch that error and set off
> > > > the alarm even before any change need to happen?
>
> > > > Thanks,
> > > > Mart :)
>
> > > > On Jan 8, 1:44 am, Thadeus Burgess  wrote:
> > > > > I can also confirm this is a bug with the new DAL.
>
> > > > > It is only caused when using upper case characters in the table or 
> > > > > field
> > > > > names. It seems that web2py converts all of the tablenames to lower 
> > > > > case
> > > > > when issuing the SQL (so your actual tables are lower regardless of 
> > > > > what
> > > > you
> > > > > specify in the python). There is something in the migrations that 
> > > > > cause
> > > > this
> > > > > to come up, because it will work just fine one run and crash on 
> > > > > another
> > > > run
> > > > > after changing some unrelated tables.
>
> > > > > I don't think the DAL should force the tables to lowercase.
>
> > > > > --
> > > > > Thadeus
>
> > > > > On Sat, Jan 8, 2011 at 12:38 AM, mart  wrote:
> > > > > > no, this is python...
>
> > > > > > not sure how it could have worked before, but the key (technogradua)
> > > > > > in .keys() is not being picked up... dal is simply pointing that out
> > > > > > with the exception being thrown. I did notice when I made the switch
> > > > > > that a few more of my mistakes got picked up (or it could be that I
> > > > > > forgot that I changed something), but regardless... since switching 
> > > > > > to
> > > > > > the latest DAL release and fixing my mistakes that it quickly picked
> > > > > > up, I have had no problems (except those that I cause). I would 
> > > > > > simply
> > > > > > take those exceptions for cash, change the case and enjoy one less
> > > > > > exception ;)
>
> > > > > > Mart :)
>
> > > > > > On Jan 8, 1:19 am, drayco  wrote:
> > > > > > > Ok, I understand your point.
>
> > > > > > > But this is a issue of DAL or what?
>
> > > > > > > because I only update web2py to trunk version
>
> > > > > > > On

[web2py] Re: empty list:reference seems like a bug

[DenesL]

On Jan 28, 4:47 pm, LightOfMooN  wrote:
> Running 1.91.6 too.
>
> db.define_table('tag',
>     Field('name', 'string'), format='%(name)s')
>
> db.define_table('rolic',
>     Field('name', 'string'),
>     Field('tags', 'list:reference tag', required=True),
>     )
>
> Add 1 rolic with empty tags, and "database administration -> db.rolic"

How are you adding that rolic?
It should not be possible with DAL since required=True.

> goes to error:
> ProgrammingError: syntax error at or near ")"
> LINE 1: SELECT  tag.id FROM tag WHERE (tag.id IN ());
>
> ERROR SNAPSHOT
> (syntax error at or near ")"
> LINE 1: SELECT  tag.id FROM tag WHERE (tag.id IN ());
>                                                   ^
> )

[web2py] Re: Can any help me with new dal in trunk?

[drayco]

Hi, I updated my trunk version

However, The same issue is still

This is the new traceback

Traceback (most recent call last):
  File "/home/drayco/web2py/gluon/restricted.py", line 188, in
restricted
exec ccode in environment
  File "/home/drayco/web2py/applications/iscada/models/cfedb.py", line
16, in 
migrate = False)
  File "/home/drayco/web2py/gluon/dal.py", line 3471, in define_table
sequence_name=sequence_name))
  File "/home/drayco/web2py/gluon/dal.py", line 3755, in __init__
"primarykey must be a list of fields from table '%s " % tablename
SyntaxError: primarykey must be a list of fields from table
'med_dnpmst_4

SnapShot

(primarykey must be a list of fields
from table 'med_dnpmst_4 )

File /home/drayco/web2py/gluon/dal.py in __init__ at line 3755

Function argument list

(self=}>, db=, tablename='med_dnpmst_4',
*fields=[, ,
, , , , ],
**args={'primarykey': ['DireccionUTR', 'Indice'], 'sequence_name':
None, 'trigger_name': None})

Code listing

3750.
3751.
3752.
3753.
3754.
3755.

3756.
3757.
3758.
3759.

if hasattr(self,'_primarykey'):
for k in self._primarykey:
if k not in self.fields:
raise SyntaxError, \
"primarykey must be a list of fields from table '%s " % tablename

else:
self[k].notnull = True

On Jan 28, 8:35 am, Massimo Di Pierro 
wrote:
> this should now be fixed in trunk
>
> On Jan 8, 2:58 pm, Thadeus Burgess  wrote:
>
> >  All I know is that tables are issued as lowercase, but you can still access
> > your table as an uppercase attribute.
>
> > There is an inconsistency in the DAL somewhere because of this... Somewhere
> > it is forgetting to convert to lower case. I don't know why converting table
> > names to lower case is forced in web2py and I disagree with it.
>
> > for example:
>
> > db = DAL()
> > db.define_table('TableA', Field('Superman'))
> > # CREATE TABLE tablea WITH FIELDS superman
> > db(db.TableA.Superman == "clark").select().first().Superman
> > # SELECT * FROM tablea WHERE superman="clark"
>
> > --
> > Thadeus
>
> > On Sat, Jan 8, 2011 at 1:17 AM, mart  wrote:
> > > really? I didn't know, thanks for pointing that out...
>
> > > just out of curiosity
>
> > > in
>
> > > in __getitem__
> > >    return dict.__getitem__(self, str(key))
> > > KeyError: 'tecnogradua'
>
> > > don't the attribute lookups get done by python ultimately?  Just
> > > trying to understand...
> > > how could this have worked if doing x.__getitem__ ? Even if dal does a
> > > string.lower() or something, once the table is named and created,
> > > would something (outside of migrate) not catch that error and set off
> > > the alarm even before any change need to happen?
>
> > > Thanks,
> > > Mart :)
>
> > > On Jan 8, 1:44 am, Thadeus Burgess  wrote:
> > > > I can also confirm this is a bug with the new DAL.
>
> > > > It is only caused when using upper case characters in the table or field
> > > > names. It seems that web2py converts all of the tablenames to lower case
> > > > when issuing the SQL (so your actual tables are lower regardless of what
> > > you
> > > > specify in the python). There is something in the migrations that cause
> > > this
> > > > to come up, because it will work just fine one run and crash on another
> > > run
> > > > after changing some unrelated tables.
>
> > > > I don't think the DAL should force the tables to lowercase.
>
> > > > --
> > > > Thadeus
>
> > > > On Sat, Jan 8, 2011 at 12:38 AM, mart  wrote:
> > > > > no, this is python...
>
> > > > > not sure how it could have worked before, but the key (technogradua)
> > > > > in .keys() is not being picked up... dal is simply pointing that out
> > > > > with the exception being thrown. I did notice when I made the switch
> > > > > that a few more of my mistakes got picked up (or it could be that I
> > > > > forgot that I changed something), but regardless... since switching to
> > > > > the latest DAL release and fixing my mistakes that it quickly picked
> > > > > up, I have had no problems (except those that I cause). I would simply
> > > > > take those exceptions for cash, change the case and enjoy one less
> > > > > exception ;)
>
> > > > > Mart :)
>
> > > > > On Jan 8, 1:19 am, drayco  wrote:
> > > > > > Ok, I understand your point.
>
> > > > > > But this is a issue of DAL or what?
>
> > > > > > because I only update web2py to trunk version
>
> > > > > > On Jan 8, 12:15 am, mart  wrote:
>
> > > > > > > Probably just being unhappy with the case :)
>
> > > > > > > tecnoGradua != tecnogradua
>
> > > > > > > Mart :)
>
> > > > > > > Field("tecnoGradua", 'string',
>
> > > > > > > On Jan 8, 12:57 am, drayco  wrote:
>
> > > > > > > > Hi, this code works with web2py 1.89.5 with mysql
>
> > > > > > > > but with web2py in trunk and mysql it dosent works.
>
> > > > > > > > db.define_table("lentes",
> > > > > > > >     audit,
> > > > > > > >     Field("tecnoGradua", 'string',
>
> > > requires=IS_IN_SET(['MONOFOCAL','BIFOC

[web2py] 2 quickies about cache

[Magnitus]

I'm trying to determine whether the built-in web2py cache will fulfill
my needs or not and thus need a clarification on the following...

Based on this completely artificial example to illustrate my
questions:

someModule.py:

def ICacheLogs(cache, X):
return db(db.log.id==X).select(db.log.ALL, cache=(cache.ram,
3600))

default.py (controller):

from someModule import ICacheLogs

def f1():
 #Verify request.vars.X and whatnot
 logs = ICacheLogs(cache, int(request.vars.X))
 #Some more logic

def f2():
 #Verify request.vars.X and whatnot
 logs = ICacheLogs(cache, int(request.vars.X))
 #Some more logic

1) If a user quickly accesses the f1 function with X set to 1 and then
again with X set to 2, will the logs result of second request be
cached on top of the logs result for first request (or worse, use the
cached result of the first request even though the parameters differ)
or will it know to cache them separately because they have different
parameters?

2) If a user quickly accesses the f1 function with X set to 1 and then
accesses the f2 function with X set to 1 also, will the logs result in
f2 be taken from the cached result from the f1 call or will it be
cached again separately because the caching is performed from a
different function in the controller?

[web2py] Re: empty list:reference seems like a bug

[LightOfMooN]

Running 1.91.6 too.

db.define_table('tag',
Field('name', 'string'), format='%(name)s')

db.define_table('rolic',
Field('name', 'string'),
Field('tags', 'list:reference tag', required=True),
)

Add 1 rolic with empty tags, and "database administration -> db.rolic"
goes to error:
ProgrammingError: syntax error at or near ")"
LINE 1: SELECT  tag.id FROM tag WHERE (tag.id IN ());

ERROR SNAPSHOT
(syntax error at or near ")"
LINE 1: SELECT  tag.id FROM tag WHERE (tag.id IN ());
  ^
)


On 29 янв, 00:09, DenesL  wrote:
> I have a table with empty list:reference fields and db admin does not
> have a problem with it.
> Running 1.91.6 .
>
> On Jan 28, 10:12 am, LightOfMooN  wrote:
>
>
>
>
>
>
>
> > It's a problem, that if i have empty list:reference, the standard
> > database administration don't work because of wrong query:
>
> > Traceback (most recent call last):
> >   File "/home/www-data/web2py/gluon/restricted.py", line 188, in
> > restricted
> >     exec ccode in environment
> >   File "/home/www-data/web2py/applications/funportal/views/
> > appadmin.html", line 191, in 
> >     
> >   File "/home/www-data/web2py/gluon/sqlhtml.py", line 1349, in
> > __init__
> >     r = field.represent(r)
> >   File "/home/www-data/web2py/gluon/dal.py", line 3113, in
> > list_ref_repr
> >     refs = r._db(r.id.belongs(ids)).select(r.id)
> >   File "/home/www-data/web2py/gluon/dal.py", line 4507, in select
> >     return self.db._adapter.select(self.query,fields,attributes)
> >   File "/home/www-data/web2py/gluon/dal.py", line 1003, in select
> >     rows = response(sql)
> >   File "/home/www-data/web2py/gluon/dal.py", line 994, in response
> >     self.execute(sql)
> >   File "/home/www-data/web2py/gluon/dal.py", line 1067, in execute
> >     return self.log_execute(*a, **b)
> >   File "/home/www-data/web2py/gluon/dal.py", line 1064, in log_execute
> >     return self.cursor.execute(*a,**b)
> > ProgrammingError: syntax error at or near ")"
> > LINE 1: SELECT  tag.id FROM tag WHERE (tag.id IN ());

Re: [web2py] Learning materials for newbie

[Richard Vézina]

Web2py book : http://www.web2py.com/book

Richard

On Fri, Jan 28, 2011 at 4:38 PM, noob.py  wrote:

> Hello,
> I'm totally new to programming, but very motivated to learn it. I'm
> especially interested in creating web application (that's why I post
> here). So, can anyone tell me what do I have to learn (except Python
> and web2py of course) and point me some good learning materials and
> resources (books, ebooks, web tutorials, etc.)?

[web2py] Learning materials for newbie

[noob.py]

Hello,
I'm totally new to programming, but very motivated to learn it. I'm
especially interested in creating web application (that's why I post
here). So, can anyone tell me what do I have to learn (except Python
and web2py of course) and point me some good learning materials and
resources (books, ebooks, web tutorials, etc.)?

[web2py] Re: Important Pycon 2011

[pallav]

Hi, same goes for the developers at my company - we will not be able
to attend Pycon 2011. Would definitely appreciate an article on your
experiences though.

On Jan 28, 4:28 pm, William  wrote:
> Sorry I can't go to Pycon 2011. But I would be appreciated if you can post
> an article about the experience on your blog.
>
> Thanks,
> Bill

[web2py] Re: The web of connected p2p web2py apps ? (or a new kind of social network)

[William]

I don't know why people are constantly talking about the NOSQL hype.
why bother them?
Sqlite is included in web2py.

I would rather to see a user admin which is better than django's.

-Bill

[web2py] Re: Important Pycon 2011

[William]

Sorry I can't go to Pycon 2011. But I would be appreciated if you can post 
an article about the experience on your blog.

Thanks,
Bill

[web2py] Important Pycon 2011

[Massimo Di Pierro]

The web2py Python tutorial has 8 registered participants. That is not
god enough. There is still a possibility it may be cancelled.

I am told web2py is easy and perhaps people do not need a tutorial but
I promise I will do my best to cover things you probably do not know
and make it worthwhile.

So if you are planning to attend PyCon 2011, I encourage to register
for the web2py tutorial "web2py secrets" and some of the other
excellent tutorials.

Massimo

Re: [web2py] Disabling the error page in production.

[Bruno Rocha]

http://web2py.com/book/default/chapter/04#Routes-on-Error


2011/1/28 David J. 

> How do I disable the error page in production?
>
> I would ideally like to replace it with a Nicer page same for 404 errors;
>
> I searched the book for error page; but I must have missed the part where
> it says disabling.
>
> Thanks.
>

[web2py] Re: Is there an alternative to Django's Pinax in the world of Web2py?

[pbreit]

PInax looks really cool and helpful. I'm not aware of anything besides 
plugins and appliances.

[web2py] Is there an alternative to Django's Pinax in the world of Web2py?

[Cai]

Hi all,

I am gonna design and develop a social app via Web2py. Before I am
getting my hands dirty, I wonder is there an alternative to Django's
Pinax in the world of Web2py?

[web2py] Re: Use the source, Luca

[Anthony]

Interesting related discussion: 
https://groups.google.com/forum/?fromgroups#!topic/comp.lang.python/Dq11ce39xtc

[web2py] Re: Pydra: new Python hosting option

[Anthony]

There's also http://www.ep.io/, also still in beta.

On Friday, January 28, 2011 4:03:13 PM UTC-5, pbreit wrote:

> Still testing but looks interesting: 
> http://www.pydra.com/
>

[web2py] Pydra: new Python hosting option

[pbreit]

Still testing but looks interesting:
http://www.pydra.com/

[web2py] Disabling the error page in production.

[David J.]

How do I disable the error page in production?

I would ideally like to replace it with a Nicer page same for 404 errors;

I searched the book for error page; but I must have missed the part 
where it says disabling.


Thanks.

Re: [web2py] Re: web2py and gae : Delete everything in the datastore

[Nathan VanHoudnos]

Thanks for the reply.

To clarify, I want to wipe everything in the production datastore on
Google's servers. If it were only as easy as clearing the development
datastore!

Cheers,

Nathan

On Fri, Jan 28, 2011 at 3:10 PM, devGS  wrote:

> Run your web2py app with a command from your GAE library and the flag -
> c.
> i.e: dev_appserver.py -c C:\web2py
>
> On Jan 28, 9:31 pm, Nathan VanHoudnos  wrote:
> > Hi,
> >
> > I'm running web2py 1.91.6 on google app engine. I'd like to delete
> > everything in the datastore and start over.
> >
> > If you have a quick solution for this, stop reading now and just tell me
> the
> > "web2py" way. :)
> >
> > There is a StackOverflow thread that I found:
> >
> > http://stackoverflow.com/questions/1062540/how-to-delete-all-datastor...
> >
> > which assumes that you setup everything in Models.py which uses syntax
> very
> > different from the DAL and I can't make heads or tails of it.
> >
> > I tried using the remote_api to do the deletion:
> >
> > vanhoudn@gauze:~/workspace/creatia-rubrics/src$ python2.5
> > ~/google_appengine/remote_api_shell.py creatia-rubrics
> > App Engine remote_api shell
> > Python 2.5.5 (r255:77872, Sep 14 2010, 17:16:34)
> > [GCC 4.4.3]
> > The db, users, urlfetch, and memcache modules are imported.
> > creatia-rubrics> from google.appengine.ext.db import GqlQuery
> > creatia-rubrics> query = GqlQuery("SELECT * FROM allRatings")
> > Traceback (most recent call last):
> >   File "", line 1, in 
> >   File
> >
> "/home/vanhoudn/google_appengine.1.4.1/google/appengine/ext/db/__init__.py"
> ,
> > line 2296, in __init__
> > model_class = class_for_kind(self._proto_query._entity)
> >   File
> >
> "/home/vanhoudn/google_appengine.1.4.1/google/appengine/ext/db/__init__.py"
> ,
> > line 266, in class_for_kind
> > raise KindError('No implementation for kind \'%s\'' % kind)
> > KindError: No implementation for kind 'allRatings'
> >
> > But it gives me this weird KindError. Before i can get to the
> >
> > db.delete(query)
> >
> > step. So how do you access the kinds that you create in models/db.py? I
> > copied the GQL statement straight from the datastore viewer on
> > appspot.comso it shouldn't be a syntax error.
> >
> > The relevant section of my models/db.py is:
> >
> > db.define_table('allRatings',
> > Field('timeend','datetime',requires= IS_NOT_EMPTY() ),
> > Field('timestart','datetime',requires= IS_NOT_EMPTY() ),
> > Field('assignmentId',requires= IS_NOT_EMPTY() ),
> > Field('experimentId',requires= IS_NOT_EMPTY() ),
> > Field('workerId',requires= IS_NOT_EMPTY() ),
> > Field('studentIds',requires= IS_NOT_EMPTY() ),
> > Field('rubricCode',requires= IS_NOT_EMPTY() ),
> > Field('ipaddress' ,default=request.client),
> > Field('comment',requires= IS_NOT_EMPTY() ),
> > Field('rawAnswers',requires= IS_NOT_EMPTY() ),
> > Field('subscores',requires= IS_NOT_EMPTY() )
> > )
> >
> > Any help would be appreciated!
> >
> > Cheers,
> > --
> > Nathan VanHoudnos
> > |- Statistics & Public Policy PhD student
> > |- Program for Interdisciplinary Education Research (PIER) Fellowship
> > |- Carnegie Mellon University
> > |-http://www.andrew.cmu.edu/user/nmv
> >
> > "Neglect of mathematics works injury to all knowledge,
> >  since he who is ignorant of it cannot know the other
> >  sciences or the things of this world." -- Roger Bacon
>



-- 
Nathan VanHoudnos
|- Statistics & Public Policy PhD student
|- Program for Interdisciplinary Education Research (PIER) Fellowship
|- Carnegie Mellon University
|- http://www.andrew.cmu.edu/user/nmv

"Neglect of mathematics works injury to all knowledge,
 since he who is ignorant of it cannot know the other
 sciences or the things of this world." -- Roger Bacon

[web2py] query in DAL

[beto (R3)]

Hey guys:

Is there a way to do this query in DAL?

SELECT
date, count(foo.items)
FROM
(
SELECT
logs.date, logs.items
FROM logs
WHERE
extract(year from logs.date) = 2010)
GROUP BY date, items
) AS foo, stock
WHERE
stock.items = foo.items
GROUP by date

Any help would be appreciated.

thanks!

[web2py] Re: web2py and gae : Delete everything in the datastore

[devGS]

Run your web2py app with a command from your GAE library and the flag -
c.
i.e: dev_appserver.py -c C:\web2py

On Jan 28, 9:31 pm, Nathan VanHoudnos  wrote:
> Hi,
>
> I'm running web2py 1.91.6 on google app engine. I'd like to delete
> everything in the datastore and start over.
>
> If you have a quick solution for this, stop reading now and just tell me the
> "web2py" way. :)
>
> There is a StackOverflow thread that I found:
>
> http://stackoverflow.com/questions/1062540/how-to-delete-all-datastor...
>
> which assumes that you setup everything in Models.py which uses syntax very
> different from the DAL and I can't make heads or tails of it.
>
> I tried using the remote_api to do the deletion:
>
> vanhoudn@gauze:~/workspace/creatia-rubrics/src$ python2.5
> ~/google_appengine/remote_api_shell.py creatia-rubrics
> App Engine remote_api shell
> Python 2.5.5 (r255:77872, Sep 14 2010, 17:16:34)
> [GCC 4.4.3]
> The db, users, urlfetch, and memcache modules are imported.
> creatia-rubrics> from google.appengine.ext.db import GqlQuery
> creatia-rubrics> query = GqlQuery("SELECT * FROM allRatings")
> Traceback (most recent call last):
>   File "", line 1, in 
>   File
> "/home/vanhoudn/google_appengine.1.4.1/google/appengine/ext/db/__init__.py" ,
> line 2296, in __init__
>     model_class = class_for_kind(self._proto_query._entity)
>   File
> "/home/vanhoudn/google_appengine.1.4.1/google/appengine/ext/db/__init__.py" ,
> line 266, in class_for_kind
>     raise KindError('No implementation for kind \'%s\'' % kind)
> KindError: No implementation for kind 'allRatings'
>
> But it gives me this weird KindError. Before i can get to the
>
> db.delete(query)
>
> step. So how do you access the kinds that you create in models/db.py? I
> copied the GQL statement straight from the datastore viewer on
> appspot.comso it shouldn't be a syntax error.
>
> The relevant section of my models/db.py is:
>
> db.define_table('allRatings',
>                 Field('timeend','datetime',requires= IS_NOT_EMPTY() ),
>                 Field('timestart','datetime',requires= IS_NOT_EMPTY() ),
>                 Field('assignmentId',requires= IS_NOT_EMPTY() ),
>                 Field('experimentId',requires= IS_NOT_EMPTY() ),
>                 Field('workerId',requires= IS_NOT_EMPTY() ),
>                 Field('studentIds',requires= IS_NOT_EMPTY() ),
>                 Field('rubricCode',requires= IS_NOT_EMPTY() ),
>                 Field('ipaddress' ,default=request.client),
>                 Field('comment',requires= IS_NOT_EMPTY() ),
>                 Field('rawAnswers',requires= IS_NOT_EMPTY() ),
>                 Field('subscores',requires= IS_NOT_EMPTY() )
>                 )
>
> Any help would be appreciated!
>
> Cheers,
> --
> Nathan VanHoudnos
> |- Statistics & Public Policy PhD student
> |- Program for Interdisciplinary Education Research (PIER) Fellowship
> |- Carnegie Mellon University
> |-http://www.andrew.cmu.edu/user/nmv
>
> "Neglect of mathematics works injury to all knowledge,
>  since he who is ignorant of it cannot know the other
>  sciences or the things of this world." -- Roger Bacon

Re: [web2py] Re: TypeError: is not JSON serializable

[w2padawan]

Hi massimo, do you know something more about this?

2011/1/26 web2py noob :
> Hi Massimo,
>
> I send you my code attached to this email.
> Very thank you for your time.
>
> On 26 ene, 16:40, Massimo Di Pierro  wrote:
>> Can you please email me your app?
>>
>> On Jan 26, 10:05 am, web2py noob  wrote:
>>
>> > I'm trying to list the db.table's content using
>> > plugin_wiki.widget('jqgrid',table='table') but despite I put in
>> > controller, view o in a wiki_page (with respective sintaxis for each)
>> > I always get "TypeError:  is not JSON serializable". My db model was
>> > generated by the app_wizard.
>>
>> > I have looked for this problem in the archive but the same solution
>> > about "deleting the SPAN" in db.define_table at model doesn't seem to
>> > work for me.
>>
>> > It's just jqgrid who's throwing the error, even if I didn't expose to
>> > view (when using plugin_wiki.widget('jqgrid',table='table') from
>> > controller)
>>
>> > what could be the problem?
>>
>> > thanks in advance.
>>
>>
>

[web2py] web2py and gae : Delete everything in the datastore

[Nathan VanHoudnos]

Hi,

I'm running web2py 1.91.6 on google app engine. I'd like to delete
everything in the datastore and start over.

If you have a quick solution for this, stop reading now and just tell me the
"web2py" way. :)

There is a StackOverflow thread that I found:

http://stackoverflow.com/questions/1062540/how-to-delete-all-datastore-in-google-app-engine


which assumes that you setup everything in Models.py which uses syntax very
different from the DAL and I can't make heads or tails of it.

I tried using the remote_api to do the deletion:

vanhoudn@gauze:~/workspace/creatia-rubrics/src$ python2.5
~/google_appengine/remote_api_shell.py creatia-rubrics
App Engine remote_api shell
Python 2.5.5 (r255:77872, Sep 14 2010, 17:16:34)
[GCC 4.4.3]
The db, users, urlfetch, and memcache modules are imported.
creatia-rubrics> from google.appengine.ext.db import GqlQuery
creatia-rubrics> query = GqlQuery("SELECT * FROM allRatings")
Traceback (most recent call last):
  File "", line 1, in 
  File
"/home/vanhoudn/google_appengine.1.4.1/google/appengine/ext/db/__init__.py",
line 2296, in __init__
model_class = class_for_kind(self._proto_query._entity)
  File
"/home/vanhoudn/google_appengine.1.4.1/google/appengine/ext/db/__init__.py",
line 266, in class_for_kind
raise KindError('No implementation for kind \'%s\'' % kind)
KindError: No implementation for kind 'allRatings'


But it gives me this weird KindError. Before i can get to the

db.delete(query)


step. So how do you access the kinds that you create in models/db.py? I
copied the GQL statement straight from the datastore viewer on
appspot.comso it shouldn't be a syntax error.

The relevant section of my models/db.py is:

db.define_table('allRatings',
Field('timeend','datetime',requires= IS_NOT_EMPTY() ),
Field('timestart','datetime',requires= IS_NOT_EMPTY() ),
Field('assignmentId',requires= IS_NOT_EMPTY() ),
Field('experimentId',requires= IS_NOT_EMPTY() ),
Field('workerId',requires= IS_NOT_EMPTY() ),
Field('studentIds',requires= IS_NOT_EMPTY() ),
Field('rubricCode',requires= IS_NOT_EMPTY() ),
Field('ipaddress' ,default=request.client),
Field('comment',requires= IS_NOT_EMPTY() ),
Field('rawAnswers',requires= IS_NOT_EMPTY() ),
Field('subscores',requires= IS_NOT_EMPTY() )
)


Any help would be appreciated!

Cheers,
-- 
Nathan VanHoudnos
|- Statistics & Public Policy PhD student
|- Program for Interdisciplinary Education Research (PIER) Fellowship
|- Carnegie Mellon University
|- http://www.andrew.cmu.edu/user/nmv

"Neglect of mathematics works injury to all knowledge,
 since he who is ignorant of it cannot know the other
 sciences or the things of this world." -- Roger Bacon

[web2py] Re: empty list:reference seems like a bug

[DenesL]

I have a table with empty list:reference fields and db admin does not
have a problem with it.
Running 1.91.6 .


On Jan 28, 10:12 am, LightOfMooN  wrote:
> It's a problem, that if i have empty list:reference, the standard
> database administration don't work because of wrong query:
>
> Traceback (most recent call last):
>   File "/home/www-data/web2py/gluon/restricted.py", line 188, in
> restricted
>     exec ccode in environment
>   File "/home/www-data/web2py/applications/funportal/views/
> appadmin.html", line 191, in 
>     
>   File "/home/www-data/web2py/gluon/sqlhtml.py", line 1349, in
> __init__
>     r = field.represent(r)
>   File "/home/www-data/web2py/gluon/dal.py", line 3113, in
> list_ref_repr
>     refs = r._db(r.id.belongs(ids)).select(r.id)
>   File "/home/www-data/web2py/gluon/dal.py", line 4507, in select
>     return self.db._adapter.select(self.query,fields,attributes)
>   File "/home/www-data/web2py/gluon/dal.py", line 1003, in select
>     rows = response(sql)
>   File "/home/www-data/web2py/gluon/dal.py", line 994, in response
>     self.execute(sql)
>   File "/home/www-data/web2py/gluon/dal.py", line 1067, in execute
>     return self.log_execute(*a, **b)
>   File "/home/www-data/web2py/gluon/dal.py", line 1064, in log_execute
>     return self.cursor.execute(*a,**b)
> ProgrammingError: syntax error at or near ")"
> LINE 1: SELECT  tag.id FROM tag WHERE (tag.id IN ());

Re: [web2py] Re: Change in URL args handling

[Jonathan Lundell]

On Jan 28, 2011, at 10:40 AM, villas wrote:
> 
>> The downside is that we lose the capability to have trailing args that are 
>> empty strings.
> 
> Hi Jonathan,
> My point is that it's only a *downside* for those that want 'trailing
> args that are empty strings'.
> Who is it that wants them??

We don't know. The problem with args is that they can be used for pretty much 
anything, and it's entirely application-dependent. So if they're being used for 
something where elements can be empty, you'll get empty trailing args. Just 
because *my* application has no use for them doesn't mean that someone else's 
might not.

> If we explicitly want to indicate empty args we can insert something
> explicit (of our own choice) to create them, eg /url~
> Otherwise strip them in the interests of cleaner, shorter args.
> 2 cts  :)

I don't think that they'll be any cleaner or shorter either way. The only way 
you'll get trailing slashes (if we end up supporting them) is by asking for a 
URL with empty trailing args. If you don't want trailing slashes, then don't 
add empty args.

That is, args=['arg1'] will generate a URL of .../arg1 regardless of which 
choice we make here.

[web2py] Re: LIKE case sensitivity: Postgres differs to MySQL => DAL not portable

[Anthony]

On Friday, January 28, 2011 12:58:30 PM UTC-5, Massimo Di Pierro wrote: 
>
> We need two steps: 
>
> 1) make it behave the same (which means case insensitive, ilike on 
> postgresql, now in trunk) 

 
Doesn't this change break backward compatibility, or are you treating this 
as a bug fix?
 

> 2) yes we can add a case_sensitive arg that defaults to True (not done 
> yet but I would take a patch).

 
If we do want to maintain backward compatibility, wouldn't the new case arg 
have to default to something like "let the RDBMS decide" -- it couldn't just 
default to True (or False) because different databases have different 
defaults, no? On the other hand, if that's not a concern, do we want 
case_sensitive to default to True -- it sounds like not all databases even 
offer that option?
 

>
> On Jan 28, 11:37 am, Anthony  wrote: 
> > What if like() had something like a 'case' argument, with three possible 
> > values: sensitive, insensitive, and rdbms_default (defaulting to 
> > rdbms_default)? 
> > 
> > We obviously need to maintain backward compatibility, but like() is a 
> web2py 
> > operator, not a specific RDBMS operator, so it would be nice if there's 
> any 
> > easy way to make sure like() calls are as portable as possible without 
> > requiring code changes. 
> > 
> > Anthony

Re: [web2py] Re: Change in URL args handling

[pbreit]

"If no one has asked for trailing slashes,  why introduce a feature which 
has to be protected forever as backward-compatible?"

Except that stripping out the trailing slash is itself a non-backwards 
compatible change. It may be OK, but let's be clear.

I don't think the browser adds the trailing slash. I believe the webserver 
redirects to the same URL with slash post-pended if it is unable to find 
something to handle the URL without the trailing slash.

Does anyone know how other frameworks handle this (Rails & Django)? We 
should also make sure we are consistent with any RFCs.

[web2py] Re: Change in URL args handling

[villas]

> The downside is that we lose the capability to have trailing args that are 
> empty strings.

Hi Jonathan,
My point is that it's only a *downside* for those that want 'trailing
args that are empty strings'.
Who is it that wants them??
If we explicitly want to indicate empty args we can insert something
explicit (of our own choice) to create them, eg /url~
Otherwise strip them in the interests of cleaner, shorter args.
2 cts  :)
-D

Re: [web2py] Re: Change in URL args handling

[Kenneth Lundström]

> Kenneth: how did you happen to notice this? How did the extra 
trailing slash get there in the first place?


I was testing an application and was using 
http://domain/controller/applications/2 when I decided to start from the 
begining with http://domain/controller/applications but I only removed 
the number not the slash. And as my program was checking the length of 
request.args and determined that length was 1. It took arg1 and tried to 
use it as an number and gave me Internal ticket. I could not understand 
what was wrong with my code until I found what I thought was as bug in 
web2py.


I understand both sides but would still consider this a bug. Maybe bug 
is a bit too strong word for it.



Kenneth


#2 follows the expectation that .../arg1 and .../arg1/ are the same, but it 
does so at the expense of treating '' differently from all other arg values.

#3 takes a different approach, flatly declaring that trailing slashes are never 
significant. The downside is that trailing empty args ('') cannot be made 
explicit in the URL (though in fairness, in current web2py they're illegal, 
so...).

We should get this resolved before Massimo releases the next stable version. 
Massimo, do you have a preference? I'm leaning toward #1 at the moment, but not 
very strongly.

[web2py] Bugfix for full CRUD internal read links

[Bernd Rothert]

The book's example for "full CRUD"

def data(): return (form=crud())

doesn't set the proper links from

.../data/select/ to
.../data/read//

they instead go to
.../read//


This patch fixes the issue:

--- a/gluon/tools.pyFri Jan 28 09:54:47 2011 -0600
+++ b/gluon/tools.pyFri Jan 28 19:27:06 2011 +0100
@@ -2668,7 +2668,7 @@
 elif args[0] == 'create':
 return self.create(args(1))
 elif args[0] == 'select':
-return self.select(args(1),linkto=self.url('read'))
+return self.select(args(1),linkto=self.url(args='read'))
 elif args[0] == 'read':
 return self.read(args(1), args(2))
 elif args[0] == 'update':

[web2py] Re: create table as select.

[DenesL]

It can be done, but why do you want to do it?.

On Jan 28, 10:42 am, vortex  wrote:
> Is it possible to join to tables and create a new table based on this
> join using only DAL?
>
> CREATE TABLE newtable AS SELECT  ta.key, ta.col1, tb.col2  FROM ta
> JOIN tb.col1 on (ta.key=tb.key)

[web2py] Re: LIKE case sensitivity: Postgres differs to MySQL => DAL not portable

[villas]

I suppose 'ilike' in PostgreSQL is similar to 'containing' in Firebird
(except you don't use wildcards in FB).



On Jan 28, 5:58 pm, Massimo Di Pierro 
wrote:
> We need two steps:
>
> 1) make it behave the same (which means case insensitive, ilike on
> postgresql, now in trunk)
> 2) yes we can add a case_sensitive arg that defaults to True (not done
> yet but I would take a patch).
>
> On Jan 28, 11:37 am, Anthony  wrote:
>
> > What if like() had something like a 'case' argument, with three possible
> > values: sensitive, insensitive, and rdbms_default (defaulting to
> > rdbms_default)?
>
> > We obviously need to maintain backward compatibility, but like() is a web2py
> > operator, not a specific RDBMS operator, so it would be nice if there's any
> > easy way to make sure like() calls are as portable as possible without
> > requiring code changes.
>
> > Anthony
>
> > On Friday, January 28, 2011 11:43:58 AM UTC-5, VP wrote:
> > > I agree with Thadeus here that "like" should be what it means in each
> > > case.  Changing the default meaning of "like" in each RDBMS will cause
> > > confusion.   "ilike" can be a web2py thing, but "like" should be
> > > specific to each RDMS.
>
> > > On Jan 28, 9:46 am, Thadeus Burgess  wrote:
> > > > I disagree! Your playing with things that shouldn't be played with.
>
> > > > Not to mention that now you have just broken some of my apps that 
> > > > perform
>
> > > > case-sensitive queries in postgres this is just plain wrong in so
> > > many
> > > > ways.
>
> > > > Add a new identifier to DAL... give me
>
> > > > db(db.table.name.like('%printer%'))
>
> > > > and then for case insensitive
>
> > > > db(db.table.name.ilike('%printer%')).
>
> > > > like would perform the actual operation that would happen from the 
> > > > RDBMS,
>
> > > > and ilike can be a web2py playing god version that makes sure all 
> > > > rdbmses
>
> > > > act the same.
>
> > > > Case sensitive search is one of the benefits of using postgres instead 
> > > > of
>
> > > > mysql!
>
> > > > --
> > > > Thadeus
>
> > > > On Fri, Jan 28, 2011 at 8:40 AM, Massimo Di Pierro <
>
> > > > massimo@gmail.com> wrote:
> > > > > I agree the behavior should be uniform. The easiest way is to make the
> > > > > LIKE always case insensitive. I am patching trunk to use ILIKE with
> > > > > postgresql.
>
> > > > > On Jan 28, 3:01 am, KMax  wrote:
> > > > > > On 7 дек 2010, 00:31, Fran  wrote:
>
> > > > > > > - minimally it should be in a FAQ (ideally in the next Book) &
> > > ideally
> > > > > > > we could have a case_sensitive=True option for the DAL like()
> > > > > > > operator...to ensure that both pgsql & mysql/sqlite existing apps
> > > > > > > didn't break, it could default differently depending on the db
> > > type?
>
> > > > > > +1 vote
> > > > > > sqlite has some issue with not ascii chars compare, but work in
> > > > > > progress
> > > > > > pgsql has ilike which works like mysql like (fix me)
>
> > > > > > I' just patch dal to use ilike in .like() query for postgres, but it
> > > > > > more cheat then solution.
>
>

[web2py] Re: Speeding up IS_IN_DB

[DenesL]

list:reference fields get an IS_IN_DB validator if no explicit
requires is defined.
Note: the assigned requires is not a list.


On Jan 28, 12:54 pm, Massimo Di Pierro 
wrote:
> Something else is wrong. If you have requires=[...] it should not
> query the db for the possible references and it should not make the
> dropdown.
>
> Can we see the entire model?
>
> Massimo
>
> On Jan 28, 10:01 am, Johann Spies  wrote:
>
> > On 28 January 2011 16:45, Massimo Di Pierro 
> > wrote:
>
> > > This:
>
> > > requires = IS_IN_DB(db, db.joernaal.id, '%(titel)s')
>
> > > indicates you want to a select/options dropbox and it takes time to
> > > populate it.
>
> > > Use instead:
>
> > > requires = [IS_IN_DB(db, db.joernaal.id,'%(titel)s')]
>
> > > so no dropbox and use autocomplete.
>
> > Thanks for the suggestion which is an improvement but it did not make a
> > difference in the speed.  The form still takes about 70 seconds to show up.
> > I suspect the list_references may be the culprit.  Maybe I must redisign the
> > database structure to handle 1 to many relationships differently.
>
> > Regards
> > Johann
> > --
> >  May grace and peace be yours in abundance through the full knowledge of God
> > and of Jesus our Lord!  His divine power has given us everything we need for
> > life and godliness through the full knowledge of the one who called us by
> > his own glory and excellence.
> >                                                     2 Pet. 1:2b,3a
>
>

[web2py] Re: LIKE case sensitivity: Postgres differs to MySQL => DAL not portable

[Massimo Di Pierro]

We need two steps:

1) make it behave the same (which means case insensitive, ilike on
postgresql, now in trunk)
2) yes we can add a case_sensitive arg that defaults to True (not done
yet but I would take a patch).

On Jan 28, 11:37 am, Anthony  wrote:
> What if like() had something like a 'case' argument, with three possible
> values: sensitive, insensitive, and rdbms_default (defaulting to
> rdbms_default)?
>
> We obviously need to maintain backward compatibility, but like() is a web2py
> operator, not a specific RDBMS operator, so it would be nice if there's any
> easy way to make sure like() calls are as portable as possible without
> requiring code changes.
>
> Anthony
>
>
>
>
>
>
>
> On Friday, January 28, 2011 11:43:58 AM UTC-5, VP wrote:
> > I agree with Thadeus here that "like" should be what it means in each
> > case.  Changing the default meaning of "like" in each RDBMS will cause
> > confusion.   "ilike" can be a web2py thing, but "like" should be
> > specific to each RDMS.
>
> > On Jan 28, 9:46 am, Thadeus Burgess  wrote:
> > > I disagree! Your playing with things that shouldn't be played with.
>
> > > Not to mention that now you have just broken some of my apps that perform
>
> > > case-sensitive queries in postgres this is just plain wrong in so
> > many
> > > ways.
>
> > > Add a new identifier to DAL... give me
>
> > > db(db.table.name.like('%printer%'))
>
> > > and then for case insensitive
>
> > > db(db.table.name.ilike('%printer%')).
>
> > > like would perform the actual operation that would happen from the RDBMS,
>
> > > and ilike can be a web2py playing god version that makes sure all rdbmses
>
> > > act the same.
>
> > > Case sensitive search is one of the benefits of using postgres instead of
>
> > > mysql!
>
> > > --
> > > Thadeus
>
> > > On Fri, Jan 28, 2011 at 8:40 AM, Massimo Di Pierro <
>
> > > massimo@gmail.com> wrote:
> > > > I agree the behavior should be uniform. The easiest way is to make the
> > > > LIKE always case insensitive. I am patching trunk to use ILIKE with
> > > > postgresql.
>
> > > > On Jan 28, 3:01 am, KMax  wrote:
> > > > > On 7 дек 2010, 00:31, Fran  wrote:
>
> > > > > > - minimally it should be in a FAQ (ideally in the next Book) &
> > ideally
> > > > > > we could have a case_sensitive=True option for the DAL like()
> > > > > > operator...to ensure that both pgsql & mysql/sqlite existing apps
> > > > > > didn't break, it could default differently depending on the db
> > type?
>
> > > > > +1 vote
> > > > > sqlite has some issue with not ascii chars compare, but work in
> > > > > progress
> > > > > pgsql has ilike which works like mysql like (fix me)
>
> > > > > I' just patch dal to use ilike in .like() query for postgres, but it
> > > > > more cheat then solution.

[web2py] Re: GAE belongs (how to map long list)

[Massimo Di Pierro]

It is supported by DAL. It maps into OR on GAE. Is it not?

On Jan 27, 3:29 pm, "Arun K.Rajeevan"  wrote:
> Hi,
>
> I know belongs is not supported on GAE
>
> Fromhttp://www.web2py.com/AlterEgo/default/show/248
>
> *it's clear that we have to convert*
>
> rows = db(purchase.buyer.belongs((kenny,cartman)))\
>          .select(orderby=purchase.quantity)
>
> *to*
> *
>
> *
> *
>
> rows = 
> (db(purchase.buyer==kenny).select()|db(purchase.buyer==cartman).select())
>
> *
> *
>
> *
> *
>
> *
> *
>
> But if the list is too big (here only kenny and cartman)
>
> *
> , it'll become quite tedious.
>
> Will someone have something to make it easier?
> for eg: a lambda expression.
> It's crucial as of now.
> Please give me a solution if you got the idea.

[web2py] Re: How to do a count distinct with DAL?

[Massimo Di Pierro]

OK. 3 is enough. Please add a google code issue and I will add it
asap. Meanwhile if you want to try build a patch, it would be a new
exercise in understainding the new dal. search for "def count" in the
file.

On Jan 28, 10:41 am, villas  wrote:
> > It seems to work in SQLite and MS-SQL though.
>
> Firebird seems OK too.

[web2py] Re: Speeding up IS_IN_DB

[Massimo Di Pierro]

Something else is wrong. If you have requires=[...] it should not
query the db for the possible references and it should not make the
dropdown.

Can we see the entire model?

Massimo

On Jan 28, 10:01 am, Johann Spies  wrote:
> On 28 January 2011 16:45, Massimo Di Pierro wrote:
>
> > This:
>
> > requires = IS_IN_DB(db, db.joernaal.id, '%(titel)s')
>
> > indicates you want to a select/options dropbox and it takes time to
> > populate it.
>
> > Use instead:
>
> > requires = [IS_IN_DB(db, db.joernaal.id,'%(titel)s')]
>
> > so no dropbox and use autocomplete.
>
> Thanks for the suggestion which is an improvement but it did not make a
> difference in the speed.  The form still takes about 70 seconds to show up.
> I suspect the list_references may be the culprit.  Maybe I must redisign the
> database structure to handle 1 to many relationships differently.
>
> Regards
> Johann
> --
>  May grace and peace be yours in abundance through the full knowledge of God
> and of Jesus our Lord!  His divine power has given us everything we need for
> life and godliness through the full knowledge of the one who called us by
> his own glory and excellence.
>                                                     2 Pet. 1:2b,3a

Re: [web2py] Re: Change in URL args handling

[Jonathan Lundell]

On Jan 28, 2011, at 9:21 AM, DenesL wrote:
> 
> 
> 
> On Jan 28, 10:59 am, Jonathan Lundell  wrote:
>> 
>> It's not so obviously a bug.
> 
> Agreed.
> 
>> URL('f',args=['arg1','arg2']) is /app/ctl/f/arg1/arg2 or 
>> /app/ctl/f/'arg1'/'arg2' (quotes added for clarity)
>> 
>> so suppose arg2 is ''; the consistent transformation is:
>> 
>> URL('f',args=['arg1','']) -> /app/ctl/f/'arg1'/'' or /app/ctl/f/arg1/ 
>> without the quotes
>> 
>> I see three defensible choices. In all cases, .../arg1 -> ['arg1']
>> 
>> 1. .../arg1/ -> ['arg1', ''] .../arg1// -> ['arg1', '', '']
>> 
>> 2. .../arg1/ -> ['arg1'] .../arg1// -> ['arg1', '']
>> 
>> 3. .../arg1/ -> ['arg1'] .../arg1// -> ['arg1']
>> 
>> #1 follows Python split/join. Each trailing slash is another empty-string 
>> arg.
>> 
>> #2 adds a trailing slash on output iff the last arg is '', and always 
>> deletes one trailing slash on input if it's present.
>> 
>> #3 ignores all trailing slashes (that's the current code)
>> 
>> #1 is the most simple, consistent and elegant, it seems to me. Its drawback 
>> is that we sort of expect that .../arg1 and .../arg1/ are the same URL. But 
>> that's not always the case, and I don't see a big problem with saying that a 
>> visible difference has consequences. Also, we're mostly generating our own 
>> URLs, so we control what they look like; they're not often being typed.
> 
> #1 also seems to go along with the spirit of the RFC where the slash
> is a segment separator.
> The only worry is that I think some browsers add the trailing slash if
> it is not there (don't quote me on this though), but does it matter?.

If a browser did that, we'd see an extra '' arg, I guess, but I wonder if that 
actually happens.

FWIW, we already see an extra '' arg when there's a trailing slash in the 
current web2py. It's not intentional; the URL regex parser has a little bug, 
and (again by accident) the logic that normally treats empty args as errors 
doesn't catch this one.

So it must be at least tolerable. Mostly. But that's how this subject came up. 
Kenneth Lundström wrote:

> I´m a little bit surprised that I havn´t noticed this before as I have used 
> len(request.args) quite much to determine the state of an operation.

Though here's a question. Kenneth also wrote:

Has it allways been like this or?

> http://./application/controller/function/args1   len(request.args) = 1
> http://./application/controller/function/args1/args2   len(request.args) 
> = 2
> 
> but
> http://./application/controller/function/args1/   len(request.args) = 2
> 
> I would have guessed that the last case would have returned length as 1


Kenneth: how did you happen to notice this? How did the extra trailing slash 
get there in the first place?

> 
>> #2 follows the expectation that .../arg1 and .../arg1/ are the same, but it 
>> does so at the expense of treating '' differently from all other arg values.
>> 
>> #3 takes a different approach, flatly declaring that trailing slashes are 
>> never significant. The downside is that trailing empty args ('') cannot be 
>> made explicit in the URL (though in fairness, in current web2py they're 
>> illegal, so...).
>> 
>> We should get this resolved before Massimo releases the next stable version. 
>> Massimo, do you have a preference? I'm leaning toward #1 at the moment, but 
>> not very strongly.
>> 

[web2py] Re: LIKE case sensitivity: Postgres differs to MySQL => DAL not portable

[Anthony]

What if like() had something like a 'case' argument, with three possible 
values: sensitive, insensitive, and rdbms_default (defaulting to 
rdbms_default)?
 
We obviously need to maintain backward compatibility, but like() is a web2py 
operator, not a specific RDBMS operator, so it would be nice if there's any 
easy way to make sure like() calls are as portable as possible without 
requiring code changes.
 
Anthony

On Friday, January 28, 2011 11:43:58 AM UTC-5, VP wrote:

> I agree with Thadeus here that "like" should be what it means in each 
> case.  Changing the default meaning of "like" in each RDBMS will cause 
> confusion.   "ilike" can be a web2py thing, but "like" should be 
> specific to each RDMS. 
>
>
> On Jan 28, 9:46 am, Thadeus Burgess  wrote: 
> > I disagree! Your playing with things that shouldn't be played with. 
> > 
> > Not to mention that now you have just broken some of my apps that perform 
>
> > case-sensitive queries in postgres this is just plain wrong in so 
> many 
> > ways. 
> > 
> > Add a new identifier to DAL... give me 
> > 
> > db(db.table.name.like('%printer%')) 
> > 
> > and then for case insensitive 
> > 
> > db(db.table.name.ilike('%printer%')). 
> > 
> > like would perform the actual operation that would happen from the RDBMS, 
>
> > and ilike can be a web2py playing god version that makes sure all rdbmses 
>
> > act the same. 
> > 
> > Case sensitive search is one of the benefits of using postgres instead of 
>
> > mysql! 
> > 
> > -- 
> > Thadeus 
> > 
> > On Fri, Jan 28, 2011 at 8:40 AM, Massimo Di Pierro < 
> > 
> > massimo@gmail.com> wrote: 
> > > I agree the behavior should be uniform. The easiest way is to make the 
> > > LIKE always case insensitive. I am patching trunk to use ILIKE with 
> > > postgresql. 
> > 
> > > On Jan 28, 3:01 am, KMax  wrote: 
> > > > On 7 дек 2010, 00:31, Fran  wrote: 
> > 
> > > > > - minimally it should be in a FAQ (ideally in the next Book) & 
> ideally 
> > > > > we could have a case_sensitive=True option for the DAL like() 
> > > > > operator...to ensure that both pgsql & mysql/sqlite existing apps 
> > > > > didn't break, it could default differently depending on the db 
> type? 
> > 
> > > > +1 vote 
> > > > sqlite has some issue with not ascii chars compare, but work in 
> > > > progress 
> > > > pgsql has ilike which works like mysql like (fix me) 
> > 
> > > > I' just patch dal to use ilike in .like() query for postgres, but it 
> > > > more cheat then solution. 
> > 
> >

[web2py] Re: GAE belongs (how to map long list)

[Arun K.Rajeevan]

I did it myself. Thanks

[web2py] Re: Change in URL args handling

[DenesL]

On Jan 28, 10:59 am, Jonathan Lundell  wrote:
>
> It's no so obviously a bug.

Agreed.

> URL('f',args=['arg1','arg2']) is /app/ctl/f/arg1/arg2 or 
> /app/ctl/f/'arg1'/'arg2' (quotes added for clarity)
>
> so suppose arg2 is ''; the consistent transformation is:
>
> URL('f',args=['arg1','']) -> /app/ctl/f/'arg1'/'' or /app/ctl/f/arg1/ without 
> the quotes
>
> I see three defensible choices. In all cases, .../arg1 -> ['arg1']
>
> 1. .../arg1/ -> ['arg1', ''] .../arg1// -> ['arg1', '', '']
>
> 2. .../arg1/ -> ['arg1'] .../arg1// -> ['arg1', '']
>
> 3. .../arg1/ -> ['arg1'] .../arg1// -> ['arg1']
>
> #1 follows Python split/join. Each trailing slash is another empty-string arg.
>
> #2 adds a trailing slash on output iff the last arg is '', and always deletes 
> one trailing slash on input if it's present.
>
> #3 ignores all trailing slashes (that's the current code)
>
> #1 is the most simple, consistent and elegant, it seems to me. Its drawback 
> is that we sort of expect that .../arg1 and .../arg1/ are the same URL. But 
> that's not always the case, and I don't see a big problem with saying that a 
> visible difference has consequences. Also, we're mostly generating our own 
> URLs, so we control what they look like; they're not often being typed.

#1 also seems to go along with the spirit of the RFC where the slash
is a segment separator.
The only worry is that I think some browsers add the trailing slash if
it is not there (don't quote me on this though), but does it matter?.

> #2 follows the expectation that .../arg1 and .../arg1/ are the same, but it 
> does so at the expense of treating '' differently from all other arg values.
>
> #3 takes a different approach, flatly declaring that trailing slashes are 
> never significant. The downside is that trailing empty args ('') cannot be 
> made explicit in the URL (though in fairness, in current web2py they're 
> illegal, so...).
>
> We should get this resolved before Massimo releases the next stable version. 
> Massimo, do you have a preference? I'm leaning toward #1 at the moment, but 
> not very strongly.
>

[web2py] Re: LIKE case sensitivity: Postgres differs to MySQL => DAL not portable

[VP]

I agree with Thadeus here that "like" should be what it means in each
case.  Changing the default meaning of "like" in each RDBMS will cause
confusion.   "ilike" can be a web2py thing, but "like" should be
specific to each RDMS.


On Jan 28, 9:46 am, Thadeus Burgess  wrote:
> I disagree! Your playing with things that shouldn't be played with.
>
> Not to mention that now you have just broken some of my apps that perform
> case-sensitive queries in postgres this is just plain wrong in so many
> ways.
>
> Add a new identifier to DAL... give me
>
> db(db.table.name.like('%printer%'))
>
> and then for case insensitive
>
> db(db.table.name.ilike('%printer%')).
>
> like would perform the actual operation that would happen from the RDBMS,
> and ilike can be a web2py playing god version that makes sure all rdbmses
> act the same.
>
> Case sensitive search is one of the benefits of using postgres instead of
> mysql!
>
> --
> Thadeus
>
> On Fri, Jan 28, 2011 at 8:40 AM, Massimo Di Pierro <
>
> massimo.dipie...@gmail.com> wrote:
> > I agree the behavior should be uniform. The easiest way is to make the
> > LIKE always case insensitive. I am patching trunk to use ILIKE with
> > postgresql.
>
> > On Jan 28, 3:01 am, KMax  wrote:
> > > On 7 дек 2010, 00:31, Fran  wrote:
>
> > > > - minimally it should be in a FAQ (ideally in the next Book) & ideally
> > > > we could have a case_sensitive=True option for the DAL like()
> > > > operator...to ensure that both pgsql & mysql/sqlite existing apps
> > > > didn't break, it could default differently depending on the db type?
>
> > > +1 vote
> > > sqlite has some issue with not ascii chars compare, but work in
> > > progress
> > > pgsql has ilike which works like mysql like (fix me)
>
> > > I' just patch dal to use ilike in .like() query for postgres, but it
> > > more cheat then solution.
>
>

Re: [web2py] Re: Change in URL args handling

[Jonathan Lundell]

On Jan 28, 2011, at 8:30 AM, villas wrote:
> 
> Stripping out trailing slashes seems like it delivers cleaner, shorter
> args.  If no one has asked for trailing slashes,  why introduce a
> feature which has to be protected forever as backward-compatible?
> 
> After all, if these extra args exist,  we're going to have to iterate
> through them seeing what they are before deciding whether they can be
> safely discarded. This leads to more lines of code;  bad!
> 
> On the other hand, if someone in the future comes up with a real use
> for these 'spurious' args, they can easily be introduced then.
> 
> My vote therefore goes for #3 - in my view a vote for shorter, cleaner
> args and less code!

That was my thinking when I implemented it that way. 

The downside is that we lose the capability to have trailing args that are 
empty strings. So if you're generating a URL with request.args = ['arg1', ''], 
it'll be treated as though the '' arg wasn't there.

Obviously that's not critical, since we can't (in general) use '' args at all 
right now.

[web2py] Re: How to do a count distinct with DAL?

[villas]

> It seems to work in SQLite and MS-SQL though.

Firebird seems OK too.

[web2py] Re: Change in URL args handling

[villas]

Hi Jonathan

Stripping out trailing slashes seems like it delivers cleaner, shorter
args.  If no one has asked for trailing slashes,  why introduce a
feature which has to be protected forever as backward-compatible?

After all, if these extra args exist,  we're going to have to iterate
through them seeing what they are before deciding whether they can be
safely discarded. This leads to more lines of code;  bad!

On the other hand, if someone in the future comes up with a real use
for these 'spurious' args, they can easily be introduced then.

My vote therefore goes for #3 - in my view a vote for shorter, cleaner
args and less code!

-D

Re: [web2py] Re: Speeding up IS_IN_DB

[Johann Spies]

On 28 January 2011 15:48, DenesL  wrote:

>
> According to your model you have two references:
> 1) joernaal.id (with autocomplete)
> 2) article.ouid (without)
>

There are also two other fields with list_references.

There are about 137000 records in article and 8200 in joernaal.

Regards
Johann
-- 
 May grace and peace be yours in abundance through the full knowledge of God
and of Jesus our Lord!  His divine power has given us everything we need for
life and godliness through the full knowledge of the one who called us by
his own glory and excellence.
2 Pet. 1:2b,3a

Re: [web2py] Re: Change in URL args handling

[Jonathan Lundell]

On Jan 28, 2011, at 4:40 AM, marius.v.niekerk wrote:
> 
> I had another problem with url argument handling that came in was
> 
> "/app/controller/function/arg1\r".
> 
> The default regex matching ( regex_args.match(request.raw_args( )) for
> the arguments would return false and then the application would
> respond with an "invalid request" error.  It is not obvious from the
> error what the reason for failure is.
> 
> Obviously this doesn't happen when visiting sites in a browsers, but
> it can be more of an issue for a json-rpc style application.
> 
> Should the url be "sanitized" beforehand?

If you're suggesting that trailing whitespace (including \r) should be treated 
as a special case, then maybe so, but it doesn't seem compelling to me: "Don't 
do that!" That is, yes, the URL should be sanitized, but by the generator, not 
the receiver. Rejecting the request gives an early warning to the developer 
that something is wrong with the URL generation.

Otherwise I think that rejecting such a URL is the right thing to do; we really 
shouldn't be editing a URL (aside from standards-based decoding), since we 
don't know what the intent was. 

We could make the error message more helpful by identifying what was wrong with 
the request. I've done a little of that already. But that's not going to be 
very helpful when the request is automated.

Re: [web2py] Re: Speeding up IS_IN_DB

[Johann Spies]

On 28 January 2011 16:45, Massimo Di Pierro wrote:

> This:
>
> requires = IS_IN_DB(db, db.joernaal.id, '%(titel)s')
>
> indicates you want to a select/options dropbox and it takes time to
> populate it.
>
> Use instead:
>
> requires = [IS_IN_DB(db, db.joernaal.id,'%(titel)s')]
>
> so no dropbox and use autocomplete.


Thanks for the suggestion which is an improvement but it did not make a
difference in the speed.  The form still takes about 70 seconds to show up.
I suspect the list_references may be the culprit.  Maybe I must redisign the
database structure to handle 1 to many relationships differently.

Regards
Johann
-- 
 May grace and peace be yours in abundance through the full knowledge of God
and of Jesus our Lord!  His divine power has given us everything we need for
life and godliness through the full knowledge of the one who called us by
his own glory and excellence.
2 Pet. 1:2b,3a

Re: [web2py] Re: Change in URL args handling

[Jonathan Lundell]

On Jan 28, 2011, at 6:05 AM, DenesL wrote:
> 
> On Jan 27, 5:58 pm, Jonathan Lundell  wrote:
>> On Jan 27, 2011, at 12:48 PM, DenesL wrote:
>> 
>> Still, it bothers me that arg1 == arg1/ != arg1//; > (optional) trailing slash> seems like an odd rule.
>> 
>> Notice also that '/'.join(['arg1', '']) is 'arg1/', not 'arg1//'.
> 
> True.
> Moreover URL('f',args=['arg1','']) is
> /app/ctl/f/arg1/
> 
> maybe that should be considered a bug as it should be
> /app/ctl/f/arg1//

It's no so obviously a bug.

URL('f',args=['arg1','arg2']) is /app/ctl/f/arg1/arg2 or 
/app/ctl/f/'arg1'/'arg2' (quotes added for clarity)

so suppose arg2 is ''; the consistent transformation is:

URL('f',args=['arg1','']) -> /app/ctl/f/'arg1'/'' or /app/ctl/f/arg1/ without 
the quotes

I see three defensible choices. In all cases, .../arg1 -> ['arg1']

1. .../arg1/ -> ['arg1', ''].../arg1// -> ['arg1', '', '']

2. .../arg1/ -> ['arg1'].../arg1// -> ['arg1', '']

3. .../arg1/ -> ['arg1'].../arg1// -> ['arg1']

#1 follows Python split/join. Each trailing slash is another empty-string arg.

#2 adds a trailing slash on output iff the last arg is '', and always deletes 
one trailing slash on input if it's present.

#3 ignores all trailing slashes (that's the current code)

#1 is the most simple, consistent and elegant, it seems to me. Its drawback is 
that we sort of expect that .../arg1 and .../arg1/ are the same URL. But that's 
not always the case, and I don't see a big problem with saying that a visible 
difference has consequences. Also, we're mostly generating our own URLs, so we 
control what they look like; they're not often being typed.

#2 follows the expectation that .../arg1 and .../arg1/ are the same, but it 
does so at the expense of treating '' differently from all other arg values.

#3 takes a different approach, flatly declaring that trailing slashes are never 
significant. The downside is that trailing empty args ('') cannot be made 
explicit in the URL (though in fairness, in current web2py they're illegal, 
so...).



We should get this resolved before Massimo releases the next stable version. 
Massimo, do you have a preference? I'm leaning toward #1 at the moment, but not 
very strongly.



> 
> since URL('f',args=['arg1','','arg3'] is
> /app/ctl/f/arg1//arg3
> 
> which is correct.

Re: [web2py] Re: How to do a count distinct with DAL?

[Thadeus Burgess]

Can we not add per-dialect identifiers to DAL... I can see adding this just
for postgres & ms sql.

--
Thadeus




On Fri, Jan 28, 2011 at 8:43 AM, Massimo Di Pierro <
massimo.dipie...@gmail.com> wrote:

> This is not supported because I am not sure all supported RDBS support
> count(distinct ...).
>
> As a way around it you can do
>
> len(db().select(db.item.of_variant,distinct=True))
>
> Massimo
>
> On Jan 28, 6:32 am, vortex  wrote:
> > How to do a count distinct with DAL?
> >
> > like:
> >
> > db().count(db.item.of_variant, distinct=True)
>

Re: [web2py] Re: LIKE case sensitivity: Postgres differs to MySQL => DAL not portable

[Thadeus Burgess]

I disagree! Your playing with things that shouldn't be played with.

Not to mention that now you have just broken some of my apps that perform
case-sensitive queries in postgres this is just plain wrong in so many
ways.

Add a new identifier to DAL... give me

db(db.table.name.like('%printer%'))

and then for case insensitive

db(db.table.name.ilike('%printer%')).

like would perform the actual operation that would happen from the RDBMS,
and ilike can be a web2py playing god version that makes sure all rdbmses
act the same.

Case sensitive search is one of the benefits of using postgres instead of
mysql!

--
Thadeus




On Fri, Jan 28, 2011 at 8:40 AM, Massimo Di Pierro <
massimo.dipie...@gmail.com> wrote:

> I agree the behavior should be uniform. The easiest way is to make the
> LIKE always case insensitive. I am patching trunk to use ILIKE with
> postgresql.
>
> On Jan 28, 3:01 am, KMax  wrote:
> > On 7 дек 2010, 00:31, Fran  wrote:
> >
> > > - minimally it should be in a FAQ (ideally in the next Book) & ideally
> > > we could have a case_sensitive=True option for the DAL like()
> > > operator...to ensure that both pgsql & mysql/sqlite existing apps
> > > didn't break, it could default differently depending on the db type?
> >
> > +1 vote
> > sqlite has some issue with not ascii chars compare, but work in
> > progress
> > pgsql has ilike which works like mysql like (fix me)
> >
> > I' just patch dal to use ilike in .like() query for postgres, but it
> > more cheat then solution.
>

[web2py] create table as select.

[vortex]

Is it possible to join to tables and create a new table based on this
join using only DAL?


CREATE TABLE newtable AS SELECT  ta.key, ta.col1, tb.col2  FROM ta
JOIN tb.col1 on (ta.key=tb.key)

Re: [web2py] Re: Callable as Field.default

[Vinicius Assef]

Massimo, good news to me.

It shoud be in the book!



On Fri, Jan 28, 2011 at 12:32 PM, Massimo Di Pierro
 wrote:
> The fact is, you can do both. If you want the values to be evaluated
> on insert, just do
>
> Field(...,default=lambda: f())
>
> instead of
>
> Field(...,default=f())
>
> If you want lazy evaluation you have to be explicit.
>
> On Jan 27, 4:51 pm, Vinicius Assef  wrote:
>> On Thu, Jan 27, 2011 at 3:54 PM, Bernd Rothert  
>> wrote:
>>
>> > Multiple inserts for the same request should get unique uuids of
>> > course, so we need a function here.
>>
>> I faced this problem some time ago.
>>
>> Default values defined in models are not assigned in INSERT time, but
>> in REQUEST time.
>>
>> So, if you have a loop with insert inside it, all records will have
>> the same default values.
>>
>> This is a web2py feature, in spite my thought explained that time that
>> it should be different. When you talk about database, default values
>> should be evaluated as in SQL INSERT: in insert time.
>>
>> --
>> Vinicius Assef.

[web2py] empty list:reference seems like a bug

[LightOfMooN]

It's a problem, that if i have empty list:reference, the standard
database administration don't work because of wrong query:

Traceback (most recent call last):
  File "/home/www-data/web2py/gluon/restricted.py", line 188, in
restricted
exec ccode in environment
  File "/home/www-data/web2py/applications/funportal/views/
appadmin.html", line 191, in 

  File "/home/www-data/web2py/gluon/sqlhtml.py", line 1349, in
__init__
r = field.represent(r)
  File "/home/www-data/web2py/gluon/dal.py", line 3113, in
list_ref_repr
refs = r._db(r.id.belongs(ids)).select(r.id)
  File "/home/www-data/web2py/gluon/dal.py", line 4507, in select
return self.db._adapter.select(self.query,fields,attributes)
  File "/home/www-data/web2py/gluon/dal.py", line 1003, in select
rows = response(sql)
  File "/home/www-data/web2py/gluon/dal.py", line 994, in response
self.execute(sql)
  File "/home/www-data/web2py/gluon/dal.py", line 1067, in execute
return self.log_execute(*a, **b)
  File "/home/www-data/web2py/gluon/dal.py", line 1064, in log_execute
return self.cursor.execute(*a,**b)
ProgrammingError: syntax error at or near ")"
LINE 1: SELECT  tag.id FROM tag WHERE (tag.id IN ());

[web2py] Best way to implement network database system with web2py

[vortex]

Hi,

I would like to implement a system of several databases on for each
store and then have the master database stored at a sever for all
company. Each store can read/write data to the local database and then
synchronize the databases. Or should I enforce read/write only on
master server database and then have only local read copies for each
store? Or only server databases with redundancy data?

I would like to know what is pros and cons of implementing such a
system based on web2py and even if this is feasible to do with web2py.
Can anyone give me some pointers?

[web2py] Re: How to do a count distinct with DAL?

[vortex]

Thank you very much!

On Jan 28, 2:43 pm, Massimo Di Pierro 
wrote:
> This is not supported because I am not sure all supported RDBS support
> count(distinct ...).
>
> As a way around it you can do
>
> len(db().select(db.item.of_variant,distinct=True))
>
> Massimo
>
> On Jan 28, 6:32 am, vortex  wrote:
>
> > How to do a count distinct with DAL?
>
> > like:
>
> > db().count(db.item.of_variant, distinct=True)
>
>

[web2py] Re: The web of connected p2p web2py apps ? (or a new kind of social network)

[Massimo Di Pierro]

yes. it does. not only tested for string types. Should work for
integer and double but probably does not work for date/datetime//time/
boolean types.

It would not take much to fix it.

On Jan 28, 7:53 am, DenesL  wrote:
> I believe the new DAL has support for CouchDB but I have not tested
> it.
> There was some work done on MongoDB on the old DAL but I have to redo
> it for the new one.
>
> On Jan 26, 6:18 pm, Offray Vladimir Luna Cárdenas 
> wrote:
>
>
>
>
>
>
>
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
>
> > Hi all,
>
> > I'm looking for which will be the app that I will do to learn web2py. I
> > like of web2py the self-contained minimalistic nature of it, and I
> > imagine a web made of web2py p2p sites that share content, but give the
> > people the ability to create apps and connect them in different ways
> > using this self-contained minimalistic framework. Today I have seen
> > Appleseed[1], Couchit[2], Analogue[3] and Scratchpad[4] and I like the
> > potential distributed p2p nature of them (the last 3 using the
> > distributed NoSQL database CouchDB).
>
> > In the view of small web2py apps connected, for example some create a
> > url shorter, some other an image gallery app, a wiki, a blog engine, and
> > so on, and you can install them on single or several web2py servers and
> > they talk each other transparently. Even, you can mount your own server
> > and import your interactions in these other sites and/or extend them
> > with your own developments. I don't know if I'm making myself clear, but
> > I think that in the context of a new kind of social network, this kind
> > of innovative appliances and visions are important and I think that the
> > self contained nature of web2py can be the key of this new kind of
> > network if we can provide easy way of making transparent p2p of web2py
> > apps talk each other, even if they are not online all the time or in the
> > same server, almost as easy as is to learn/use web2py.
>
> > [1]http://opensource.appleseedproject.org/docs/future/appleseed/
> > [2]http://couch.it/about
> > [3]http://www.anologue.com/
> > [4]http://scratchpad.cmlenz.net/about/
>
> > The thing is that you will need something like a NoSQL database or DCVS
> > as CouchDB or Fossil respectively as a storage back-end in that
> > scenario, instead of the usual SQL Database provided by DAL in web2py.
> > �Can this kind of thing be made on web2py?
>
> > Cheers,
>
> > Offray
> > -BEGIN PGP SIGNATURE-
> > Version: GnuPG v1.4.11 (GNU/Linux)
> > Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org/
>
> > iQEcBAEBAgAGBQJNQKvXAAoJEGiex2828ICwU+sIANV9IA2K0IFZ9RqDge68Qr7C
> > 0XCGoVK1TYzKATXKBWRPuVJWQyLHglnU9IxkVnZQmsbZ43tS85cqRONQHKSzn+Hx
> > IuVUgQE8y6WF3MXpHFGhDd7nFesktTRkWj5MTrCKtfcNHZfOcHgtXeCGJ+TnzE0/
> > 2cvlWVDU+4abt4QBC7hJlN3mgZ6f0tfzrVQKvElztAbv+7rpleuvSslQr8+6feWE
> > FSMzYKUfdgga4bSqTOXwyVO4mtZk/VwhrwNx15bt8NWiTzzAFlOC70ms9tbgPTop
> > Jb9XHzZjOAywt73CgoiqyIftbjLjdtx3AoUPS+Z41rX5DjQnAr1OZTWcax68ECM=
> > =bWow
> > -END PGP SIGNATURE-

[web2py] Re: Speeding up IS_IN_DB

[Massimo Di Pierro]

This:

requires = IS_IN_DB(db, db.joernaal.id, '%(titel)s')

indicates you want to a select/options dropbox and it takes time to
populate it.

Use instead:

requires = [IS_IN_DB(db, db.joernaal.id,'%(titel)s')]

so no dropbox and use autocomplete.


On Jan 28, 5:54 am, Johann Spies  wrote:
> On 28 January 2011 13:30, Lucas D'Avila  wrote:
>
> > Hi !
>
> > You can be more specific? have any suggestions to improve this?
>
> OK. For the following model, calling DAL.create it takes 65 seconds to open
> the form using web2py's own webserver and 35 seconds when using Apache +
> WSGI.  Both too long:
>
> db.define_table("artikel",
>                 Field("joernaal_id",
>                       db.joernaal,
>                       requires = IS_IN_DB(db, db.joernaal.id,
>                                           '%(titel)s')),
> #                      widget =SQLFORM.widgets.autcomplete),
>                 Field("outeur_id", 'list:reference outeur'),
>                 Field("instansie_id", 'list:reference instansie'),
>                 Field("titel", "string", notnull=True),
>                 Field("opsomming", "text", notnull=True),
>                 Field("sleutelwoorde", "text", notnull=True),
>                 Field("vakgebied", "string", default=None),
>                 Field("publikasiejaar", "integer", default=None),
>                 Field("begin_bladsy",  default=None),
>                 Field("laaste_bladsy", default=None),
>                 Field("volume", "string", default=None),
>                 Field('uitgawe', default=None),
>                 Field('pub_tipe', default = None),
>                 Field("taal", "string",  default=None),
>                 Field("isi_indeks", default = None),
>                 Field("isap_indeks", default = None),
>                 Field("scopus_verwysing",
>                       requires=IS_EMPTY_OR(IS_URL())),
>                 Field("dokument_tipe"),
>                 Field('ouid', 'integer',
>                       requires = IS_EMPTY_OR(IS_IN_DB(db, 'article.ouid'))),
>                 signature)
>
> I don't know what is causing this.  I just  guess it may the reference
> fields.
>
> Regards
> Johann
>
> --
>  May grace and peace be yours in abundance through the full knowledge of God
> and of Jesus our Lord!  His divine power has given us everything we need for
> life and godliness through the full knowledge of the one who called us by
> his own glory and excellence.
>                                                     2 Pet. 1:2b,3a