Derek, the main issue isn't truncation at insert time. In a web2py
DAL-mediated create table statement, DAL code unilaterally reduces MySQL
varchar lengths to 255, whether the specific version of MySQL could
tolerate a longer varchar or not. The developer says, column abc should be
There are historical reason for this and I do not oppose to change it since
modern mysql versions support longer varchar.
You can change this yourlself:
db = DAL('mysql://...'_
db._adapter.maxcharlength = 1024 # or whatever you want
If we change the default in web2py this would trigger a
In general, I would say it's not a good idea to silently change the
explicitly set length of a field. Either pass the length to the database
and let the database throw an exception, or raise an exception in web2py
(the former is probably preferable, since web2py won't know the true limit
of
OK. I removed the maxcharlength from dal.py (in trunk).
We now need to understand what will happen to existing mysql apps.
On Saturday, 22 June 2013 13:55:01 UTC-5, Anthony wrote:
In general, I would say it's not a good idea to silently change the
explicitly set length of a field. Either pass
The main problem is that the failure is silent. It makes no sense that a
developer declares a field to be length 1000, and DAL arbitrarily reduces
that to 255 instead of providing an error message. I understand why 255
may be a safe default limit for MySQL; but if so then fail the field
It's not web2py's fault that MySQL silently truncates data.
http://www.davidpashley.com/blog/databases/mysql/silently-truncated
On Wednesday, June 19, 2013 5:52:26 AM UTC-7, Chris wrote:
The main problem is that the failure is silent. It makes no sense that a
developer declares a field to
It would probably be difficult to keep DAL up to date with DBMS releases --
would hate to have to rev some part of web2py every time even one of the
supported DBMSs has a version change. And even then, version alone may not
answer the question, since max field lengths can be affected by
that's more a place for unittesting the app itself than having web2py to
check for it for every db (and every version of engine) at all times.
It's true that DAL absracts away the 90% of incompatibilities, but still
you *need* to evaluate your choices when it comes to a production app,
being
I don't think it's smart to let DAL migrate your tables in production.
Much better to write your own scripts to handle it.
Then of course you should test those scripts before you get to the
production instance.
The simplest and easiest place to create and test the scripts is on your
The main problem is that the truncation is done silently. In my case, we
were creating new data models with fields like string(1000) and just
recently a team member noted the result in the database was varchar(255).
It violates the principle of least amazement :) that a directive to
create
Can you tell us what the model was before and after migration?
Massimo
On Jan 22, 10:02 am, Jonathan Z. jzem...@gmail.com wrote:
I have a number of fields specifying a length 255 (some as large as
2K). On a recent schema migrate, web2py truncated all of these fields
to 255, resulting in
Massimo,
Here is an example of one of the tables that got a truncated field:
before...
db.define_table(thing,
Field(user_id, db.auth_user, notnull=True, readable=False,
writable=False),
Field(title, string, length=128, notnull=True, unique=True,
required=True),
Field(slug, string,
It's probably also important to note that the before table existed
since 1.85.x. I keep the migrate=False flag set on it, until I make
a change. As I noted previously, the change happened on 1.91.6. So
the issue is data loss affected by changes in the web2py DAL.
I've been digging around, and
I agree that is the problem:
Field(description, string, length=2048),
according to: http://dev.mysql.com/doc/refman/5.0/en/char.html
Values in VARCHAR columns are variable-length strings. The length can
be specified as a value from 0 to 255 before MySQL 5.0.3, and 0 to
65,535 in 5.0.3 and later
Thanks for checking it out. In the mean time, I'm working around the
problem by overriding maxcharlength right after setting db, like this:
db = DAL(...)
db._adapter.maxcharlength = 65535
Now I just need to restore a bunch of truncated data :-(
On Jan 22, 1:06 pm, Massimo Di Pierro
15 matches
Mail list logo
