[web2py] Re: AJAX in Web2py -> Synchronous

[Phoboss]

Ohhh, OK, Anthony.
Yes, my version is the same.
And yes I'm reffering to  .
I deleted them, because I thought it was for commenting out (nearly
everything was greyed out).

>From your link:
"Old browsers will treat your JS code as one long HTML comment. On the
other hand, new JavaScript-aware browsers will normally interpret JS
code between the tags  and "

Thank you for the clarification!

Best Regards

Phoboss

On 28 Jan., 01:17, Anthony  wrote:
> On Thursday, January 27, 2011 6:55:24 PM UTC-5, Phoboss wrote:
>
> > OK, I tried to change the code of web2py_ajax.html BUT all function
> > code was commented out!! What is going on?
>
> Here's the file in 
> trunk:http://code.google.com/p/web2py/source/browse/applications/welcome/vi...
>
> Is your version the same? When you say the code is commented out, are you
> referring to the  just inside the script tags? If so, that is
> commonly done so that older browsers that don't support Javascript won't end
> up displaying the Javascript code as if it were plain text (the opening and
> closing HTML comment tags tell the browser to ignore everything in between).
> Seehttp://www.javascripter.net/faq/hidingjs.htm.
>
> Anthony

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

[KMax]

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] Speeding up IS_IN_DB

[Johann Spies]

I have a lot of foreign keys in a database of which some tables have more
than 30 records.  What is happening is that  if a link to add a record
is selected it takes a long time before the form appears because all the
cross referencess in the IS_IN_DB-dropdowns have to be assembled.

How do I speed the process up?

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] Speeding up IS_IN_DB

[Lucas D'Avila]

Hi !

You can be more specific? have any suggestions to improve this?

--

Lucas D'Avila
http://flavors.me/lucasdavila
Em 28/01/2011 09:19, "Johann Spies"  escreveu:

[web2py] Re: WSGI apache -- WSGIScriptAlias as /python and not just plain /

[Fran]

I'm guessing that nothing has changed here since I see the self-same problem 
now.

I'm packaging Sahana (& hence Web2Py) to run on OSGeo Live 
(http://live.osgeo.org)
We cannot have a dedicated vhost in this environment so I need to be able to 
run off a subdirectory.

Since WSGI seems impossible here, I'm starting to convert to mod_proxy.

F

Re: [web2py] Speeding up IS_IN_DB

[Johann Spies]

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

Re: [web2py] Speeding up IS_IN_DB

[Lucas D'Avila]

ops! sorry my last comment is for another post :( ,
please ignore what I said ...

--

Lucas D'Avila
http://flavors.me/lucasdavila
Em 28/01/2011 09:54, "Johann Spies"  escreveu:

Re: [web2py] Re: PDF Reports with Pisa

[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

Re: [web2py] Speeding up IS_IN_DB

[Alexandre Andrade]

I think you need manually create index(es) in the database.



2011/1/28 Johann Spies 

> I have a lot of foreign keys in a database of which some tables have more
> than 30 records.  What is happening is that  if a link to add a record
> is selected it takes a long time before the form appears because all the
> cross referencess in the IS_IN_DB-dropdowns have to be assembled.
>
> How do I speed the process up?
>
> 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
>
>


-- 
Atenciosamente


Alexandre Andrade
Hipercenter.com Classificados Gratuitos e Inteligentes

Re: [web2py] Re: PDF Reports with Pisa

[António Ramos]

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] How to do a count distinct with DAL?

[vortex]

How to do a count distinct with DAL?

like:

db().count(db.item.of_variant, distinct=True)

Re: [web2py] Speeding up IS_IN_DB

[Johann Spies]

On 28 January 2011 14:09, Alexandre Andrade wrote:

> I think you need manually create index(es) in the database.
>

I did create indexes although I do not think it should be necessary for
id-fields in the light of the following quote from Postgresql documentation:

"PostgreSQL automatically creates a unique index when a unique
constraint or a primary key is defined for a table. The index covers
the columns that make up the primary key or unique columns (a
multicolumn index, if appropriate), and is the mechanism that enforces
the constraint."

Creating indexes did not make a difference to my problem.

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: django admin like app/plugin in web2py

[rif]

Yes, it is an amazing time saver.

On Jan 27, 11:56 pm, William  wrote:
> Just vote it!
> why nobody care this? They claim django admin is the kill feature of django.

[web2py] web2py on free hosting with no shell or httpd.conf access

[Leon]

Hi, I got interested in web2py after seeing the no install/
configuration comment on the web2py homepage. Is it possible to copy
the web2py folder to a free hosting account and somehow get up and
running?
The account I currently have has python (but only able to execute
python files with .cgi extension) and mod_wsgi. My account doesn't
have shell access or access to httpd.conf though.

So is this possible to do?

Thanks.

[web2py] table referencing?

[Oinquer]

Bear with me my language is not english, so ill try to be plain and
straight

i have a table that references another 2 tables.
when im generating the form works nicely as i want, but when i
retrieve the list with a db select all i dont get the referenced names
of the tables...i get only the id's...how should i do it to get the
names ('nome')? thanks.
im thinking about a join, but cant seem to do it

db.define_table('edificios',
   Field('nome'),
   Field('morada'))

db.define_table('tipoavaria',
   Field('nome'))

db.define_table('avariasdb',
   Field('user', db.auth_user, default=auth.user_id,
writable=False,readable=False),
   Field('edificio', db.edificios),
   Field('piso'),
   Field('tipo', db.tipoavaria),
   Field('descricao', 'string', widget=SQLFORM.widgets.text.widget),
   Field('data', 'datetime', default=request.now, writable=False))

db.avariasdb.edificio.requires = IS_IN_DB(db, 'edificios.id',
'edificios.nome', zero=T('Choose One'))
db.avariasdb.tipo.requires = IS_IN_DB(db, 'tipoavaria.id',
'tipoavaria.nome', zero=T('Choose One'))

[web2py] Re: Change in URL args handling

[marius.v.niekerk]

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?

On Jan 28, 12:58 am, Jonathan Lundell  wrote:
> On Jan 27, 2011, at 12:48 PM, DenesL wrote:
>
>
>
>  Now, trailing slashes are stripped, so the first two examples about give 
>  ['arg1'], as does /a/c/f/arg1/
>
> >>> Maybe that should be parsed as ['arg1', '', '', '', '']
>
> >> Maybe, but it seems to me that it's confusing unless we also recognize a 
> >> single trailing slash as an empty arg. I don't have a strong opinion.
>
> > Note that the number of empty strings ('') is one less than the number
> > of slashes:
>
> > /arg1/
> > /arg1/empty/empty/empty/empty/nothing_here
>
> Yes.
>
> 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//'.
>
> I'm open to changing it if you (or someone else) feels strongly about it--I'd 
> just have to change a call to rstrip to a conditional trim-one-character if 
> the string endswith('/'), so it's not a big deal. The important thing is for 
> it to be well defined.

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

[Bruno Rocha]

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 Rocha
http://about.me/rochacbruno/bio

[web2py] Re: Speeding up IS_IN_DB

[DenesL]

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

How many records do you have in joernaal and in article tables?.


On Jan 28, 6: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

[web2py] Re: What is web2py best practice basis for modular site development?

[kenji4569]

I am developing a website with many features required my client, using
web2py.
So, I'd also like to see the best practice for modular site
development.

In my development, I made two applications for a website,
one is for front, and the other is for admin site.
And I think it worked well,
though obviously it required much effort for developing multi-
application.
The choice would depend on the degree of loose coupling required in
each system.
Anyway, components and plugins are still great ideas,
which I found helpful for writing modular codes in web programming.

Besides, it would be important to
"minimize the code in models" (http://web2py.com/book/default/chapter/
11)
for single large application.
Not only because of performance issue, but also because of clean
global scope.

In this regard, current published plugins are largely written in
models directory,
while I found few plugins written primarily in modules directory.
I think writing in models is much easier,
but would have some deficits for developping a modular large
application.
But it would also depend on ones needs.
Personally, I follow the coding style as in gluon.tools.Auth, Crud,
and Mail,
with writing modules directory.

Kind regards,
Kenji

On 1月28日, 午後3:59, Kenneth Lundström 
wrote:
> My gut tells one application, having applications share layout, database
> and all is not piece of cake.
>
> But I guess it depends on the application, but I would make it as one
> application.
>
> Kenneth
>
>
>
>
>
>
>
> > Dear web2py users,
>
> > I am developing a website that will have many features, some of which
> > are not yet specified by my client. Therefore and for other reasons, I
> > would like to develop it in a modular fashion.
>
> > Should I base my website on a web2py site with a single application,
> > with modularity achieved using Components and Plugins?
>
> > Would it be better and/or easier to have a multi-application web2py
> > site with a masterapp and CAS, along with shared layout, database,
> > session, etc.?
>
> > Do any of you have any other suggestions for web2py site development
> > modularity best practices?
>
> > Thanks for your help in advance.
>
> > Love and peace,
>
> > Joe

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

[DenesL]

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: What is web2py best practice basis for modular site development?

[kenji4569]

I am developing a website with many features required my client, using
web2py. So, I'd also like to see the best practice for modular site
development.

In my development, I made two applications for a website, one is for
front, and the other is for admin site. And I think it worked well,
though obviously it required much effort for developing multi-
application. The choice would depend on the degree of loose coupling
required in each system. Anyway, components and plugins are great
ideas, which I found helpful for writing modular codes in web
programming.

Besides, it would be important to "minimize the code in
models" (http://web2py.com/book/default/chapter/11) for single large
application. Not only because of performance issue, but also because
of clean global scope.

In this regard, current published plugins are largely written in
models directory, while I found few plugins written primarily in
modules directory. I think writing in models is much easier, but would
have some deficits for developping a modular large application.
However it would also depend on ones needs. Personally, I follow the
coding style as in gluon.tools.Auth, Crud, and Mail, with writing
modules directory.

Kind regards,
Kenji

On 1月28日, 午後3:59, Kenneth Lundström 
wrote:
> My gut tells one application, having applications share layout, database
> and all is not piece of cake.
>
> But I guess it depends on the application, but I would make it as one
> application.
>
> Kenneth
>
>
>
>
>
>
>
> > Dear web2py users,
>
> > I am developing a website that will have many features, some of which
> > are not yet specified by my client. Therefore and for other reasons, I
> > would like to develop it in a modular fashion.
>
> > Should I base my website on a web2py site with a single application,
> > with modularity achieved using Components and Plugins?
>
> > Would it be better and/or easier to have a multi-application web2py
> > site with a masterapp and CAS, along with shared layout, database,
> > session, etc.?
>
> > Do any of you have any other suggestions for web2py site development
> > modularity best practices?
>
> > Thanks for your help in advance.
>
> > Love and peace,
>
> > Joe

[web2py] Re: web2py on free hosting with no shell or httpd.conf access

[carlo]

In general if you have wsgi, you need just to set wsgihandler.py
(without extension in some implementations) as your startup script,
supposed you have Python 2.5 or 2.6 of course.
But you should look into your hosting instructions about configuring a
wsgi application in their environment.

On 28 Gen, 08:54, Leon  wrote:
> Hi, I got interested in web2py after seeing the no install/
> configuration comment on the web2py homepage. Is it possible to copy
> the web2py folder to a free hosting account and somehow get up and
> running?
> The account I currently have has python (but only able to execute
> python files with .cgi extension) and mod_wsgi. My account doesn't
> have shell access or access to httpd.conf though.
>
> So is this possible to do?
>
> Thanks.

[web2py] Re: Change in URL args handling

[DenesL]

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//

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

which is correct.

[web2py] Re: table referencing?

[DenesL]

The generic formula for a 3 way join is:

db.define_table('a',db.Field('name'))
db.define_table('b',db.Field('name'))
db.define_table('t',db.Field('name'),db.Field('aid',db.a),db.Field('bid',db.b))
rows=db().select(db.t.name,db.a.name,db.b.name,
  left=[db.a.on(db.a.id==db.t.aid),db.b.on(db.b.id==db.t.bid)])

which in your case would be:

rows=db().select(db.avariasdb.ALL, db.edificios.nome,
db.tipoavaria.nome,
  left=[db.edificios.on(db.edificios.id==db.avariasdb.edificio,
db.tipoavaria.on(db.tipoavaria.id==db.avariasdb.tipo] )


On Jan 28, 5:33 am, Oinquer  wrote:
> Bear with me my language is not english, so ill try to be plain and
> straight
>
> i have a table that references another 2 tables.
> when im generating the form works nicely as i want, but when i
> retrieve the list with a db select all i dont get the referenced names
> of the tables...i get only the id's...how should i do it to get the
> names ('nome')? thanks.
> im thinking about a join, but cant seem to do it
>
> db.define_table('edificios',
>    Field('nome'),
>    Field('morada'))
>
> db.define_table('tipoavaria',
>    Field('nome'))
>
> db.define_table('avariasdb',
>    Field('user', db.auth_user, default=auth.user_id,
> writable=False,readable=False),
>    Field('edificio', db.edificios),
>    Field('piso'),
>    Field('tipo', db.tipoavaria),
>    Field('descricao', 'string', widget=SQLFORM.widgets.text.widget),
>    Field('data', 'datetime', default=request.now, writable=False))
>
> db.avariasdb.edificio.requires = IS_IN_DB(db, 'edificios.id',
> 'edificios.nome', zero=T('Choose One'))
> db.avariasdb.tipo.requires = IS_IN_DB(db, 'tipoavaria.id',
> 'tipoavaria.nome', zero=T('Choose One'))

[web2py] Re: Callable as Field.default

[Massimo Di Pierro]

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] Re: Can any help me with new dal in trunk?

[Massimo Di Pierro]

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','BIFOCAL','MULTIFOCAL']),label="Num.
> > > > > > > de Graduaciones"),
> > > > > > >     Field("material", "string", requires=IS_IN_SET(['MICA
> > > > CR-39','ORMA
> > > > > > > 1.50','HIGH INDEX','THIN & LITE 1.67
> > > > > > > ASFÉRICA','POLICARBONATO','CRISTAL'])),
> > > > > > >     Field("tipo", "string",requires=IS_NULL_OR(IS_IN_SET(['FLAT
> > > > > > > TOP','BLEND O YOUNGER','PROGRESIVOS','PROGRESIVOS VARILUX COMFORT
> > > > > > > NE','PROGRESIVOS COMPACTOS','PROGRESIVOS VARILUX COMFORT
> > SHORT']))),
> > > > > > >     Field("tecnoVisual",
>
> > 'string',requires=IS_NULL_OR(IS_IN_SET(['PHOTOGRAY','TRANSITIONS'])),label=
> > > > "Tecnologia
> > > > > > > de Visualización"),
> > > > > > >     Field("tratamiento",
> > "string",requires=IS_NULL_OR(IS_IN_SET(['CON
> > > > > > > ANTIRREFLEJANTE','ESPEJEADO','CRIZAL FORTE','CRIZAL ALIZÉ']))),
> > > > > > >     Field('limitup','double', writable=False, readable=False),
> > > > > > >     Field('limitdown','double', writable=False, readable=False),
> > > > > > >     Field("promo", "double",
> > requires=[IS_NOT_EMPTY(error_message='No
> > > > > > > puede estar vacio'),IS_FLOAT_IN_RANGE(0,1,error_message='Debe
> > ser
> > > > > > > un numero positivo entre 0 y 1')], label='Precio de
> > Promoción'),
> > > > > > >     Field("precio", "double", writable=False, readable=False),
> > > > > > >     Field("costo", "double", writable=False, readable=False),
> > > > > > >     Field("observaciones","text", writable=False,
> > readable=False))
>
> > > > > > > T

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

[Massimo Di Pierro]

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: How to do a count distinct with DAL?

[DenesL]

The SQL command would be
SELECT COUNT(DISTINCT item.of_variant) FROM item;

but I believe that is not something you can build in the DAL
currently.
In addition that SQL command might not be supported by all the backend
DBs.
It seems to work in SQLite and MS-SQL though.

So you have two options:
1) len( db().select(db.item.of_variant, distinct=True) )
2) db.executesql('SELECT COUNT(DISTINCT item.of_variant) FROM item;')
if it is supported by the DB you are using.


On Jan 28, 7:32 am, vortex  wrote:
> How to do a count distinct with DAL?
>
> like:
>
> db().count(db.item.of_variant, distinct=True)

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

[Massimo Di Pierro]

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: 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

[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: 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] 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] 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 ());

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] 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: 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.
>

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: 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: 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 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 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

[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

[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.

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: 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.
>
>

[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: GAE belongs (how to map long list)

[Arun K.Rajeevan]

I did it myself. Thanks

[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. 
> > 
> >

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: 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

[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: 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: 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: 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

[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: 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] 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':

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] 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

[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: 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

[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: 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 ());

[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

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] 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

[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!

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] 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.

[web2py] Pydra: new Python hosting option

[pbreit]

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

[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] Re: Use the source, Luca

[Anthony]

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

[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: 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.

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] 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

[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] 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

[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] 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.)?

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] 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 ());

[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: 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] 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?

[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

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']

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

[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] Learning materials for newbie

[Vasile Ermicioi]

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


+ http://w3schools.com/

[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

[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: 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: 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

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: 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':

[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.

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]

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