Menu
▾
▴
openwebwork-devel
|
From: John J. <jj...@as...> - 2007-06-25 21:34:24
|
Hi, I am trying to get my development copy of webwork working. In running wwdb_upgrade, I get the message > Upgrading database from version 19 to 20... > (Version 20 adds locations, location_addresses, set_locations and > set_locations_user tables to database, and add restrict_ip to set and > set_user.) > > An error occured while running the system upgrade code for version 20: > DBD::mysql::db do failed: Incorrect sub part key. The used key part > isn't a string, the used length is longer than the key part or the > table handler doesn't support unique sub keys at ./wwdb_upgrade line 248. I don't know if this is a bug in the script, perhaps related to my version of mysql (4.0.20) (in which case I will be happy to file a bug report), or if it is caused by a problem on my end. Any thoughts? John |
|
From: P. G. L. <gl...@um...> - 2007-06-26 11:35:15
|
Hi John,
I'm running MySQL 4.1.20 on my servers, and think the script ran fine
there. The offending line is
$dbh->do("CREATE TABLE locations (location_id TINYBLOB NOT NULL,
description TEXT, PRIMARY KEY (location_id(1000)))");
My bet from the error message is that the assignment of a prefix of 1000
bytes is causing the error; I wonder if the implementation of TINYBLOB is
having trouble with the 1000 byte value on your machine, or in MySQL 4.0.
In fact, the MySQL 4.0/4.1 documentation indicates that "Before MySQL
4.1.2, the limit is 255 bytes for all tables." So that sounds like it's
likely to be the problem. If you change the prefix value to 255 it should
work for you, and we might want to document somewhere that the assumption
is that users are running MySQL 4.1.2 or better (or change the 1000 to
255).
Gavin
--
P Gavin LaRose, PhD | gl...@um... | 734.764.6454 | ...you have
Program Manager, Instructional Technology | to respect someone who can
Mathematics Dept, University of Michigan | spell Tuesday, even if they
http://www.math.lsa.umich.edu/~glarose/ | can't spell it right. -Milne
On 2007-06-25 [14:34] John Jones wrote:
> Hi,
>
> I am trying to get my development copy of webwork working. In running
> wwdb_upgrade, I get the message
>
>> Upgrading database from version 19 to 20...
>> (Version 20 adds locations, location_addresses, set_locations and
>> set_locations_user tables to database, and add restrict_ip to set and
>> set_user.)
>>
>> An error occured while running the system upgrade code for version 20:
>> DBD::mysql::db do failed: Incorrect sub part key. The used key part
>> isn't a string, the used length is longer than the key part or the
>> table handler doesn't support unique sub keys at ./wwdb_upgrade line 248.
> I don't know if this is a bug in the script, perhaps related to my
> version of mysql (4.0.20) (in which case I will be happy to file a bug
> report), or if it is caused by a problem on my end. Any thoughts?
>
> John
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> OpenWeBWorK-Devel mailing list
> Ope...@li...
> https://lists.sf.net/lists/listinfo/openwebwork-devel
>
>
>
|
|
From: John J. <jj...@as...> - 2007-07-17 18:45:13
|
Hi,
I tried the change below and have a partially working system. I still
get errors in the course, so I decided to create a new course. When I
do that (using the command line utility), I get an error
DBD::mysql::db do failed: Specified key was too long. Max key length
is 500 at /opt/devel/webwork-modperl/lib/WeBWorK/DB/Schema/NewSQL/Std.pm
line 111.
Are these key lengths specified inside webwork (so that I can reduce
them for this system)?
John
P. Gavin LaRose wrote:
> Hi John,
>
> I'm running MySQL 4.1.20 on my servers, and think the script ran fine
> there. The offending line is
> $dbh->do("CREATE TABLE locations (location_id TINYBLOB NOT NULL,
> description TEXT, PRIMARY KEY (location_id(1000)))");
> My bet from the error message is that the assignment of a prefix of 1000
> bytes is causing the error; I wonder if the implementation of TINYBLOB is
> having trouble with the 1000 byte value on your machine, or in MySQL 4.0.
>
> In fact, the MySQL 4.0/4.1 documentation indicates that "Before MySQL
> 4.1.2, the limit is 255 bytes for all tables." So that sounds like it's
> likely to be the problem. If you change the prefix value to 255 it should
> work for you, and we might want to document somewhere that the assumption
> is that users are running MySQL 4.1.2 or better (or change the 1000 to
> 255).
>
> Gavin
>
>
|
|
From: P. G. L. <gl...@um...> - 2007-07-18 12:08:02
|
Hi John,
I can't see anywhere in the WeBWorK code that the key length is defined.
However, if the database has some funny definition it would throw an error
whenever you bumped into it. The only place I can see a length of 500 is
in the location_addresses table, so I'd be tempted to try and make sure
that there isn't still a residual error with that. My solution would be
the "heavy club" method, of dropping the tables I think might be offending
and then recreating them, e.g.,
mysql> use webwork;
mysql> drop table locations;
mysql> drop table location_addresses;
mysql> create table locations (location_id tinyblob not null,
> description text, primary_key (location_id(255)));
mysql> create table location_addresses ((location_id tinyblob not null,
> ip_mask tinyblob not null, primary key (location_id(255),
> ip_mask(255)));
Gavin
--
P Gavin LaRose, PhD | gl...@um... | 734.764.6454 | ...you have
Program Manager, Instructional Technology | to respect someone who can
Mathematics Dept, University of Michigan | spell Tuesday, even if they
http://www.math.lsa.umich.edu/~glarose/ | can't spell it right. -Milne
On 2007-07-17 [11:45] John Jones wrote:
> Hi,
>
> I tried the change below and have a partially working system. I still get
> errors in the course, so I decided to create a new course. When I do that
> (using the command line utility), I get an error
>
> DBD::mysql::db do failed: Specified key was too long. Max key length is 500
> at /opt/devel/webwork-modperl/lib/WeBWorK/DB/Schema/NewSQL/Std.pm line 111.
>
> Are these key lengths specified inside webwork (so that I can reduce them for
> this system)?
>
> John
>
>
> P. Gavin LaRose wrote:
>> Hi John,
>>
>> I'm running MySQL 4.1.20 on my servers, and think the script ran fine
>> there. The offending line is
>> $dbh->do("CREATE TABLE locations (location_id TINYBLOB NOT NULL,
>> description TEXT, PRIMARY KEY (location_id(1000)))");
>> My bet from the error message is that the assignment of a prefix of 1000
>> bytes is causing the error; I wonder if the implementation of TINYBLOB is
>> having trouble with the 1000 byte value on your machine, or in MySQL 4.0.
>>
>> In fact, the MySQL 4.0/4.1 documentation indicates that "Before MySQL
>> 4.1.2, the limit is 255 bytes for all tables." So that sounds like it's
>> likely to be the problem. If you change the prefix value to 255 it should
>> work for you, and we might want to document somewhere that the assumption
>> is that users are running MySQL 4.1.2 or better (or change the 1000 to
>> 255).
>>
>> Gavin
>>
>>
>
>
>
>
|
|
From: John J. <jj...@as...> - 2007-07-18 17:38:04
|
Thanks for the suggestion Gavin, but it didn't work, giving the same
error for location_addresses. This seems to be because there are two
parts to the key, and 255+255>500.
I noticed that in lib/WeBWorK/DB/Schema/NewSQL/Std.pm, there is a place
where 255 is specified as part of a key length. I changed that to 25
(which might be a more sensible value anyway), and addcourse seemed to
get farther. Now the error is
skipping creation of 'problem_merged' table: no create_table method
When I go into the new course, things seem ok until I create a problem
set, and then try to edit the list of problems in the set. Then I get
the same error I was getting on the older course:
|Can't call method "get_fields_where" on an undefined value at
/opt/devel/webwork-modperl/lib/WeBWorK/DB.pm line 717.
|
Call stack
The information below can help locate the source of the problem.
* |in WeBWorK::DB::listLocations called at line 597 of
/opt/devel/webwork-modperl/lib/WeBWorK/ContentGenerator/Instructor/ProblemSetDetail.pm|
* |in
WeBWorK::ContentGenerator::Instructor::ProblemSetDetail::extraSetFields
called at line 344 of
/opt/devel/webwork-modperl/lib/WeBWorK/ContentGenerator/Instructor/ProblemSetDetail.pm|
* |in
WeBWorK::ContentGenerator::Instructor::ProblemSetDetail::FieldTable
called at line 1685 of
/opt/devel/webwork-modperl/lib/WeBWorK/ContentGenerator/Instructor/ProblemSetDetail.pm|
* |in WeBWorK::ContentGenerator::Instructor::ProblemSetDetail::body
called at line 152 of
/opt/devel/webwork-modperl/lib/WeBWorK/Template.pm|
* |in WeBWorK::Template::template called at line 486 of
/opt/devel/webwork-modperl/lib/WeBWorK/ContentGenerator.pm|
* |in WeBWorK::ContentGenerator::content called at line 194 of
/opt/devel/webwork-modperl/lib/WeBWorK/ContentGenerator.pm|
* |in WeBWorK::ContentGenerator::go called at line 338 of
/opt/devel/webwork-modperl/lib/WeBWorK.pm|
This seems to be connected to the locations business.
John
P. Gavin LaRose wrote:
> Hi John,
>
> I can't see anywhere in the WeBWorK code that the key length is
> defined. However, if the database has some funny definition it would
> throw an error whenever you bumped into it. The only place I can see
> a length of 500 is in the location_addresses table, so I'd be tempted
> to try and make sure that there isn't still a residual error with
> that. My solution would be the "heavy club" method, of dropping the
> tables I think might be offending and then recreating them, e.g.,
> mysql> use webwork;
> mysql> drop table locations;
> mysql> drop table location_addresses;
> mysql> create table locations (location_id tinyblob not null,
> > description text, primary_key (location_id(255)));
> mysql> create table location_addresses ((location_id tinyblob not
> null,
> > ip_mask tinyblob not null, primary key (location_id(255),
> > ip_mask(255)));
>
> Gavin
>
|
|
From: P. G. L. <gl...@um...> - 2007-07-18 18:30:10
|
Hi John,
It looks to me as if this is a continuing problem with the definition of
the database fields. In my version of DB.pm line 717 invokes
$self->{locations}->get_fields_where, so it looks as if the accessor to
the locations table in the database isn't getting properly defined.
I am sure that, but feel obligated to ask whether, your database.conf file
includes the stanzas in $dbLayouts{sql_single} for the locations and
location_addresses tables. That would be the easiest explanation for the
error.
Gavin
--
P Gavin LaRose, PhD | gl...@um... | 734.764.6454 | ...you have
Program Manager, Instructional Technology | to respect someone who can
Mathematics Dept, University of Michigan | spell Tuesday, even if they
http://www.math.lsa.umich.edu/~glarose/ | can't spell it right. -Milne
On 2007-07-18 [10:38] John Jones wrote:
> Thanks for the suggestion Gavin, but it didn't work, giving the same error
> for location_addresses. This seems to be because there are two parts to the
> key, and 255+255>500.
>
> I noticed that in lib/WeBWorK/DB/Schema/NewSQL/Std.pm, there is a place where
> 255 is specified as part of a key length. I changed that to 25 (which might
> be a more sensible value anyway), and addcourse seemed to get farther. Now
> the error is
>
> skipping creation of 'problem_merged' table: no create_table method
>
> When I go into the new course, things seem ok until I create a problem set,
> and then try to edit the list of problems in the set. Then I get the same
> error I was getting on the older course:
>
> |Can't call method "get_fields_where" on an undefined value at
> /opt/devel/webwork-modperl/lib/WeBWorK/DB.pm line 717.
> |
>
>
> Call stack
>
> The information below can help locate the source of the problem.
>
> * |in WeBWorK::DB::listLocations called at line 597 of
> /opt/devel/webwork-modperl/lib/WeBWorK/ContentGenerator/Instructor/ProblemSetDetail.pm|
> * |in
> WeBWorK::ContentGenerator::Instructor::ProblemSetDetail::extraSetFields
> called at line 344 of
> /opt/devel/webwork-modperl/lib/WeBWorK/ContentGenerator/Instructor/ProblemSetDetail.pm|
> * |in
> WeBWorK::ContentGenerator::Instructor::ProblemSetDetail::FieldTable
> called at line 1685 of
> /opt/devel/webwork-modperl/lib/WeBWorK/ContentGenerator/Instructor/ProblemSetDetail.pm|
> * |in WeBWorK::ContentGenerator::Instructor::ProblemSetDetail::body
> called at line 152 of
> /opt/devel/webwork-modperl/lib/WeBWorK/Template.pm|
> * |in WeBWorK::Template::template called at line 486 of
> /opt/devel/webwork-modperl/lib/WeBWorK/ContentGenerator.pm|
> * |in WeBWorK::ContentGenerator::content called at line 194 of
> /opt/devel/webwork-modperl/lib/WeBWorK/ContentGenerator.pm|
> * |in WeBWorK::ContentGenerator::go called at line 338 of
> /opt/devel/webwork-modperl/lib/WeBWorK.pm|
>
> This seems to be connected to the locations business.
>
> John
>
>
>
>
>
> P. Gavin LaRose wrote:
>> Hi John,
>>
>> I can't see anywhere in the WeBWorK code that the key length is defined.
>> However, if the database has some funny definition it would throw an error
>> whenever you bumped into it. The only place I can see a length of 500 is
>> in the location_addresses table, so I'd be tempted to try and make sure
>> that there isn't still a residual error with that. My solution would be
>> the "heavy club" method, of dropping the tables I think might be offending
>> and then recreating them, e.g.,
>> mysql> use webwork;
>> mysql> drop table locations;
>> mysql> drop table location_addresses;
>> mysql> create table locations (location_id tinyblob not null,
>> > description text, primary_key (location_id(255)));
>> mysql> create table location_addresses ((location_id tinyblob not null,
>> > ip_mask tinyblob not null, primary key (location_id(255),
>> > ip_mask(255)));
>>
>> Gavin
>>
>
>
|
|
From: John J. <jj...@as...> - 2007-07-18 18:45:23
|
P. Gavin LaRose wrote:
> I am sure that, but feel obligated to ask whether, your database.conf
> file includes the stanzas in $dbLayouts{sql_single} for the locations
> and location_addresses tables. That would be the easiest explanation
> for the error.
That was it. I admit that I do not dutifully check for differences
between database.conf and database.conf.dist. I just made the former a
symbolic link to the latter to avoid this in the future.
That raises another question, with the current contents of
database.conf.dist, is there anything anyone but the most sophisticated
system administrator would change? If not, why not make the small
simplification of changing it to be database.conf?
John
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X