[web2py] Re: AJAX in Web2py - Synchronous
Ohhh, OK, Anthony. Yes, my version is the same. And yes I'm reffering to !-- and //-- . 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 script and /script Thank you for the clarification! Best Regards Phoboss On 28 Jan., 01:17, Anthony abasta...@gmail.com 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 !-- and //-- 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
On 7 дек 2010, 00:31, Fran francisb...@gmail.com 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
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
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 johann.sp...@gmail.com escreveu:
[web2py] Re: WSGI apache -- WSGIScriptAlias as /python and not just plain /
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
On 28 January 2011 13:30, Lucas D'Avila lucass...@gmail.com 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
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 johann.sp...@gmail.com escreveu:
Re: [web2py] Re: PDF Reports with Pisa
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 msenecal...@gmail.com 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 msenecal...@gmail.com wrote: This is nice stuff! On Jan 26, 9:56 pm, Lucas D'Avila lucass...@gmail.com 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
I think you need manually create index(es) in the database. 2011/1/28 Johann Spies johann.sp...@gmail.com 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
what about reportlab? 2011/1/28 Lucas D'Avila lucass...@gmail.com 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 msenecal...@gmail.com 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 msenecal...@gmail.com wrote: This is nice stuff! On Jan 26, 9:56 pm, Lucas D'Avila lucass...@gmail.com 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?
How to do a count distinct with DAL? like: db().count(db.item.of_variant, distinct=True)
Re: [web2py] Speeding up IS_IN_DB
On 28 January 2011 14:09, Alexandre Andrade alexandrema...@gmail.comwrote: 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
Yes, it is an amazing time saver. On Jan 27, 11:56 pm, William ycw...@gmail.com 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
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?
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
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 jlund...@pobox.com 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//; ignore exactly one
(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
I use something like this:
/app/controllers/manage.py
@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)
/app/controllers/manage.py
Bruno Rocha
http://about.me/rochacbruno/bio
[web2py] Re: Speeding up IS_IN_DB
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 johann.sp...@gmail.com wrote:
On 28 January 2011 13:30, Lucas D'Avila lucass...@gmail.com 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?
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 kenneth.t.lundst...@gmail.com 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)
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 off...@riseup.net 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?
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 kenneth.t.lundst...@gmail.com 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
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 leon.san.em...@gmail.com 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
On Jan 27, 5:58 pm, Jonathan Lundell jlund...@pobox.com wrote:
On Jan 27, 2011, at 12:48 PM, DenesL wrote:
Still, it bothers me that arg1 == arg1/ != arg1//; ignore exactly one
(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?
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 oinq...@gmail.com 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
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 vinicius...@gmail.com wrote: On Thu, Jan 27, 2011 at 3:54 PM, Bernd Rothert roth...@googlemail.com 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?
this should now be fixed in trunk
On Jan 8, 2:58 pm, Thadeus Burgess thade...@thadeusb.com 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 msenecal...@gmail.com 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 thade...@thadeusb.com 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 msenecal...@gmail.com 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 antrod...@gmail.com 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 msenecal...@gmail.com wrote:
Probably just being unhappy with the case :)
tecnoGradua != tecnogradua
Mart :)
Field(tecnoGradua, 'string',
On Jan 8, 12:57 am, drayco antrod...@gmail.com 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))
This is the 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/movil/models/db.py,
line
272, in module
Field(observaciones,text,
[web2py] Re: LIKE case sensitivity: Postgres differs to MySQL = DAL not portable
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 mkostri...@gmail.com wrote: On 7 дек 2010, 00:31, Fran francisb...@gmail.com 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?
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 billyara...@gmail.com 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?
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 billyara...@gmail.com 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
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 johann.sp...@gmail.com wrote:
On 28 January 2011 13:30, Lucas D'Avila lucass...@gmail.com 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)
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 denes1...@yahoo.ca 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 off...@riseup.net 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?
Thank you very much! On Jan 28, 2:43 pm, 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 billyara...@gmail.com 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
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
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 module p 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
Massimo, good news to me. It shoud be in the book! On Fri, Jan 28, 2011 at 12:32 PM, Massimo Di Pierro massimo.dipie...@gmail.com 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 vinicius...@gmail.com wrote: On Thu, Jan 27, 2011 at 3:54 PM, Bernd Rothert roth...@googlemail.com 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.
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
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 mkostri...@gmail.com wrote:
On 7 дек 2010, 00:31, Fran francisb...@gmail.com 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?
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 billyara...@gmail.com 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
On Jan 28, 2011, at 6:05 AM, DenesL wrote:
On Jan 27, 5:58 pm, Jonathan Lundell jlund...@pobox.com wrote:
On Jan 27, 2011, at 12:48 PM, DenesL wrote:
Still, it bothers me that arg1 == arg1/ != arg1//; ignore exactly one
(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
On 28 January 2011 16:45, Massimo Di Pierro massimo.dipie...@gmail.comwrote: 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
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
On 28 January 2011 15:48, DenesL denes1...@yahoo.ca 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
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?
It seems to work in SQLite and MS-SQL though. Firebird seems OK too.
Re: [web2py] Re: Change in URL args handling
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
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 thade...@thadeusb.com 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 mkostri...@gmail.com wrote:
On 7 дек 2010, 00:31, Fran francisb...@gmail.com 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
On Jan 28, 10:59 am, Jonathan Lundell jlund...@pobox.com 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)
I did it myself. Thanks
[web2py] Re: LIKE case sensitivity: Postgres differs to MySQL = DAL not portable
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 thad...@thadeusb.com 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 mkost...@gmail.com wrote:
On 7 дек 2010, 00:31, Fran franc...@gmail.com 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
On Jan 28, 2011, at 9:21 AM, DenesL wrote:
On Jan 28, 10:59 am, Jonathan Lundell jlund...@pobox.com 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
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 johann.sp...@gmail.com wrote: On 28 January 2011 16:45, Massimo Di Pierro massimo.dipie...@gmail.comwrote: 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?
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 villa...@gmail.com wrote: It seems to work in SQLite and MS-SQL though. Firebird seems OK too.
[web2py] Re: GAE belongs (how to map long list)
It is supported by DAL. It maps into OR on GAE. Is it not? On Jan 27, 3:29 pm, Arun K.Rajeevan the1.a...@gmail.com wrote: Hi, I know belongs is not supported on GAE Fromhttp://www.web2py.com/AlterEgo/default/show/248http://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
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 abasta...@gmail.com 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 thad...@thadeusb.com 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 mkost...@gmail.com wrote:
On 7 дек 2010, 00:31, Fran franc...@gmail.com 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
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 massimo.dipie...@gmail.com 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 johann.sp...@gmail.com wrote: On 28 January 2011 16:45, Massimo Di Pierro massimo.dipie...@gmail.comwrote: 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
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 massimo.dipie...@gmail.com
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 abasta...@gmail.com 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 thad...@thadeusb.com 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 mkost...@gmail.com wrote:
On 7 дек 2010, 00:31, Fran franc...@gmail.com 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.
It can be done, but why do you want to do it?. On Jan 28, 10:42 am, vortex billyara...@gmail.com 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
The book's example for full CRUD
def data(): return (form=crud())
doesn't set the proper links from
.../data/select/table to
.../data/read/table/id
they instead go to
.../read/table/id
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: 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
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
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
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 abas...@gmail.com 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
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
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 vladsale...@yandex.ru 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 module p 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
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 console, line 1, in module
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
Hi massimo, do you know something more about this?
2011/1/26 web2py noob web2py.n...@gmail.com:
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 massimo.dipie...@gmail.com wrote:
Can you please email me your app?
On Jan 26, 10:05 am, web2py noob web2py.n...@gmail.com 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
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 nathan...@gmail.com 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 console, line 1, in module
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
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
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 vitali@geniestills.com 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 nathan...@gmail.com 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 console, line 1, in module
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.
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
Still testing but looks interesting: http://www.pydra.com/
[web2py] Re: Pydra: new Python hosting option
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
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?
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?
PInax looks really cool and helpful. I'm not aware of anything besides plugins and appliances.
Re: [web2py] Disabling the error page in production.
http://web2py.com/book/default/chapter/04#Routes-on-Error 2011/1/28 David J. da...@styleflare.com 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
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
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)
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
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 ycw...@gmail.com 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
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
Web2py book : http://www.web2py.com/book Richard On Fri, Jan 28, 2011 at 4:38 PM, noob.py noob...@hotmail.com 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
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
class 'psycopg2.ProgrammingError'(syntax error at or near )
LINE 1: SELECT tag.id FROM tag WHERE (tag.id IN ());
^
)
On 29 янв, 00:09, DenesL denes1...@yahoo.ca 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 vladsale...@yandex.ru 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 module
p
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
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?
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 module
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
type 'exceptions.SyntaxError'(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=Table {'indice': gluon.dal.Field object at 0x2...ractual':
gluon.dal.Field object at 0x25b25d0}, db=DAL {'_lastsql': SET
sql_mode='NO_BACKSLASH_ES...tables': [], '_migrate': True,
'_pool_size': 10}, tablename='med_dnpmst_4',
*fields=[gluon.dal.Field object, gluon.dal.Field object,
gluon.dal.Field object, gluon.dal.Field object, gluon.dal.Field
object, gluon.dal.Field object, gluon.dal.Field 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 massimo.dipie...@gmail.com
wrote:
this should now be fixed in trunk
On Jan 8, 2:58 pm, Thadeus Burgess thade...@thadeusb.com 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 msenecal...@gmail.com 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 thade...@thadeusb.com 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 msenecal...@gmail.com 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 antrod...@gmail.com 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 msenecal...@gmail.com wrote:
Probably just being unhappy with the case :)
tecnoGradua != tecnogradua
Mart :)
Field(tecnoGradua, 'string',
On Jan 8, 12:57 am, drayco antrod...@gmail.com wrote:
Hi, this code works with web2py 1.89.5
[web2py] Re: empty list:reference seems like a bug
On Jan 28, 4:47 pm, LightOfMooN vladsale...@yandex.ru 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
class 'psycopg2.ProgrammingError'(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?
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 antrod...@gmail.com 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 module
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
type 'exceptions.SyntaxError'(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=Table {'indice': gluon.dal.Field object at 0x2...ractual':
gluon.dal.Field object at 0x25b25d0}, db=DAL {'_lastsql': SET
sql_mode='NO_BACKSLASH_ES...tables': [], '_migrate': True,
'_pool_size': 10}, tablename='med_dnpmst_4',
*fields=[gluon.dal.Field object, gluon.dal.Field object,
gluon.dal.Field object, gluon.dal.Field object, gluon.dal.Field
object, gluon.dal.Field object, gluon.dal.Field 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 massimo.dipie...@gmail.com
wrote:
this should now be fixed in trunk
On Jan 8, 2:58 pm, Thadeus Burgess thade...@thadeusb.com 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 msenecal...@gmail.com 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 thade...@thadeusb.com 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 msenecal...@gmail.com 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 antrod...@gmail.com wrote:
Ok, I understand your point.
But this is a issue of DAL or what?
because I only update web2py to
Re: [web2py] query in DAL
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)
Please, Sqlite is not NOSQL, but a small, portable rdbms 2011/1/28 William ycw...@gmail.com 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.
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. da...@styleflare.com 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
Web2py book : http://www.web2py.com/book + http://w3schools.com/
[web2py] Re: GAE belongs (how to map long list)
I use belong on GAE quite frequently these days. Arun - you found an outdated post. :( christian
[web2py] Re: Learning materials for newbie
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
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 denes1...@yahoo.ca 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 massimo.dipie...@gmail.com 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 johann.sp...@gmail.com wrote: On 28 January 2011 16:45, Massimo Di Pierro massimo.dipie...@gmail.comwrote: 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
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 nathan...@gmail.com 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 vitali@geniestills.com 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 nathan...@gmail.com 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 console, line 1, in module
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
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
oops. Thanks
On Jan 28, 12:33 pm, Bernd Rothert roth...@googlemail.com wrote:
The book's example for full CRUD
def data(): return (form=crud())
doesn't set the proper links from
.../data/select/table to
.../data/read/table/id
they instead go to
.../read/table/id
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
ILIKE is not the same as containing. It is a case insensitive LIKE
On Jan 28, 12:23 pm, villas villa...@gmail.com 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 massimo.dipie...@gmail.com
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 abasta...@gmail.com 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 thad...@thadeusb.com 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 mkost...@gmail.com wrote:
On 7 дек 2010, 00:31, Fran franc...@gmail.com 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
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 ml.richard.vez...@gmail.com wrote: Web2py book : http://www.web2py.com/book Richard On Fri, Jan 28, 2011 at 4:38 PM, noob.py noob...@hotmail.com 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
I treat this as a bug fix. On Jan 28, 12:52 pm, Anthony abasta...@gmail.com 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 abas...@gmail.com 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
