I strongly suggest you move this discussion to a private discussion
with Denes.
The DAL has limited support for legacy tables and all the work on this
topic was done by Denes.
I doubt anybody else can help you and it is a complex matter.
Massimo
On Dec 20, 12:09 pm, sushanth wrote:
> thanks t
thanks thats got fix,if i nesrt any value ,i am getting below error
RACEBACK
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
Traceback (most recent call last):
File "/home/sushanth/Desktop/web2py/gluon/restricted.py", line 188, in
restricted
exec ccode in environment
File
"/home
db.users.team.requires = IS_IN_DB(db, 'dogs.teamname', '%
(dogs.teamname)')
should be
db.users.team.requires = IS_IN_DB(db, 'dogs.teamname', '%
(teamname)s')
On Dec 20, 11:40 am, sushanth wrote:
> db=DAL('mysql://root:test1234...@localhost/new')
>
> db.define_table('dogs',
> Field('id'),
db=DAL('mysql://root:test1234...@localhost/new')
db.define_table('dogs',
Field('id'),
Field('teamname'),primarykey=['teamname'],migrate=True
)
db.define_table('users',
Field('name'),
Field('team',db.dogs)
)
db.users.name.requires = IS_NOT_EMPTY()
db.users.team.re
Thanks Jim,
I just fixed it in trunk and posting 1.90.6. Thanks for reporting the
issue.
Massimo
On Dec 20, 11:02 am, iiijjjiii wrote:
> I get an error if I try to copy a row that has a date field.
>
> >>> import copy
> >>> db.define_table('test_table', db.Field('test_field', 'date'),
> >>> mi
I was able to get around the problem by converting the row to a
dictionary.
>>> import copy
>>> db.define_table('test_table', db.Field('test_field', 'date'), migrate=True)
>>> db.test_table.insert(test_field='2010-12-20')
1
>>> row = db(db.test_table.id==1).select()[0]
>>> row_copy = copy.copy(row
I get an error if I try to copy a row that has a date field.
>>> import copy
>>> db.define_table('test_table', db.Field('test_field', 'date'), migrate=True)
>>> db.test_table.insert(test_field='2010-12-20')
1
>>> row = db(db.test_table.id==1).select()[0]
>>> row_copy = copy.copy(row)
Traceback
What should the 'reference' string to be in the case the they is more
than one field?
On Dec 19, 11:55 pm, sushanth wrote:
> Found mysql two issues in new dal.py
>
> First issues
>
> mysql VARCHAR length should be 0 to 255,but web2py default varchar value was
> set to length = 512,if some forgot
I think I have fixed the former issue length now defaults to 255 for
mysql.
I am not sure how to fix the second issue and I will wait to form a
suggestion from Denes.
Massimo
On Dec 19, 11:55 pm, sushanth wrote:
> Found mysql two issues in new dal.py
>
> First issues
>
> mysql VARCHAR length sh
Found mysql two issues in new dal.py
First issues
mysql VARCHAR length should be 0 to 255,but web2py default varchar value was
set to length = 512,if some forgot to declare varchar length he will get
error message key too long.
Second issue
After creating FK in the model
if we declare
db.d
This issue is resolved in 1.90.3.
Thanks!
On Dec 19, 2:05 am, berubejd wrote:
> I started receiving this traceback on the console after the upgrade:
>
> Traceback (most recent call last):
> File "web2py.py", line 20, in
> File "gluon/widget.py", line 781, in start
> File "gluon/shell.py",
Thanks Gary, just fixed it in 1.90.4
On Dec 19, 3:06 pm, Gary Herron wrote:
> In 1.90.3, my SQLFORM calls are failing with
>
> Traceback(most recent call last):
>
> File"/home/gherron/Dropbox/projects/web2py/gluon/restricted.py",line188,inrestricted
> execccodeinenvironment
>
> Fil
In 1.90.3, my SQLFORM calls are failing with
Traceback(most recent call last):
File"/home/gherron/Dropbox/projects/web2py/gluon/restricted.py",line188,inrestricted
execccodeinenvironment
File"/home/gherron/Dropbox/projects/web2py/applications/ServeITS/controllers/default.py",line233,in
Looks like you are trying store on a session something that is not
pickable.
Can you show us what objects are your storing in the session?
It will help me figure out what is wrong.
Massimo
On Dec 19, 11:47 am, czamb wrote:
> Thanks for the fast reply.
> Unfortunately, after upgrade to 1.90.3 an
Thanks for the fast reply.
Unfortunately, after upgrade to 1.90.3 and restart, the same result as
before:
Traceback (most recent call last):
File "c:\web2py\gluon\main.py", line 453, in wsgibase
session._try_store_on_disk(request, response)
File "c:\web2py\gluon\globals.py", line 402, in _
All the issues raised should now be fixed in 1.90.3
On Dec 19, 10:14 am, mdipierro wrote:
> fixing in trunk.
>
> On Dec 19, 5:28 am, selecta wrote:
>
> > self reference with IS_IN_DB pointing to self
>
> > Field('parent', 'reference mytable', requires =
> > IS_EMPTY_OR(IS_IN_DB(db,'mytable.id',
fixing in trunk.
On Dec 19, 5:28 am, selecta wrote:
> self reference with IS_IN_DB pointing to self
>
> Field('parent', 'reference mytable', requires =
> IS_EMPTY_OR(IS_IN_DB(db,'mytable.id','%(name)s'))),
>
> this does not work any more
>
> On Dec 18, 8:38 pm, mdipierro wrote:
>
> > This is a
fixing this in trunk.
On Dec 19, 4:05 am, berubejd wrote:
> I started receiving this traceback on the console after the upgrade:
>
> Traceback (most recent call last):
> File "web2py.py", line 20, in
> File "gluon/widget.py", line 781, in start
> File "gluon/shell.py", line 194, in run
>
Great!, I will test tomorrow!.
self reference with IS_IN_DB pointing to self
Field('parent', 'reference mytable', requires =
IS_EMPTY_OR(IS_IN_DB(db,'mytable.id','%(name)s'))),
this does not work any more
On Dec 18, 8:38 pm, mdipierro wrote:
> This is a major - major release mostly because it includes the new
> DAL.
>
> It
I started receiving this traceback on the console after the upgrade:
Traceback (most recent call last):
File "web2py.py", line 20, in
File "gluon/widget.py", line 781, in start
File "gluon/shell.py", line 194, in run
File "", line 1, in
File "applications\Jellybean_Kingdom\controllers\
from trunk VirtualFields is working well! Thanks!
But, 1.90.2 still has this line: if callable(method)... and virtual
fields not working.
I'll wait next update to upgrade my working sites.
Thank you, new dal seen to be much faster!
2010/12/19 tomt
> Updating to 1.90.2 fixed all the mysq
Updating to 1.90.2 fixed all the mysql problems I listed and all my
apps are working again.
Thanks alot - Tom
On Dec 18, 7:13 pm, tomt wrote:
> I upgraded to Version 1.90.1 and all of my applications that use mysql
> stopped working. The traceback shows:
>
> Traceback (most recent call last):
web2py team rocks :)
All problems (virtualfields and missing ssl) should be fixed in
1.90.2. out now!
On Dec 18, 9:09 pm, Bruno Rocha wrote:
> Crashes in shell too:
>
> >>> rows = db(db.products.id>0).select()
> >>> class virtual(object):
>
> ... def test(self):
> ... return 'ok'
> ...>>> rows.setvir
yes you need to
easy_install ssl
sorry about this. This is actually a problem with pymysql and they
should make the dependency optional. I will contact them.
Massimo
On Dec 18, 7:13 pm, tomt wrote:
> I upgraded to Version 1.90.1 and all of my applications that use mysql
> stopped working. The
Congratulations, great work!
For your information: an older version of an app that I'm working on
crashes immediately as shown below. Maybe it helps you fixing
something in the new DAL... in this app I used authorization as in the
reddish example app... the newer version with the auth module runs
f
I upgraded to Version 1.90.1 and all of my applications that use mysql
stopped working. The traceback shows:
Traceback (most recent call last):
File "/home/xa21/workspace/webpy4/gluon/restricted.py", line 188, in
restricted
exec ccode in environment
File "/home/xa21/workspace/webpy4/applic
28 matches
Mail list logo
