From: Larry M. <lar...@ro...> - 2006-10-29 20:09:41
|
> @unit test failures for db2 and MSSQL: > Those should be fixed for g2.2 if we want to remove the "experimental" > label > for them. DB2 support is already non-experimental. If anything, let's refer to it as "Regressed". (I'm already investigating the 3 new errors.) -------------------- Larry Menard "Defender of Geese and of All Things Natural" E-mail and MSN Messenger: lar...@ro... Web: http://ca.geocities.com/lar...@ro... ----- Original Message ----- From: "Andy Staudacher" <an...@ee...> To: <gal...@li...> Sent: Sunday, October 29, 2006 2:37 PM Subject: Re: [Gallery-devel] Alter all DB2 tables due to UTF8charactervsbyte length > Thanks for testing. > > @4x STRING size for DB2: > This change is not as easy as it sounds. We need to create upgrade code > too! > And this upgrade code should run for DB2 only. > > Based on your feedback i'll commit first the easy fix (truncate counting > bytes instead of characters). > Then we'll figure out how to upgrade DB2 only (probably need to add XML to > only generate changes for specified DBMS but still update schema version > for > all DBMS to keep them in sync'). > Finally we can write the upgrade xml files and do the generate-sql change > in > the same changelist. > > @unit test failures for db2 and MSSQL: > Those should be fixed for g2.2 if we want to remove the "experimental" > label > for them. > > - Andy > > Larry Menard wrote: >> Ok, core.SessionTest.testLoadSessionDataExpiredSession >> runs clean in isolation on the new schema too, so I'd say the >> schema change is good to go. >> >> Andy, will you be doing it, or shall I? >> Larry Menard wrote: >> Hang on, I take it back... >> core.SessionTest.testLoadSessionDataExpiredSession runs clean >> on the original schema (though the tests with the original >> schema were run in isolation, that might make a difference). >> >> So let me look into the >> core.SessionTest.testLoadSessionDataExpiredSession failure >> before we make the change. >>> Larry Menard wrote: >> My test install with 4x STRING column >> lengths went well, so I ren the whole suite of unit tests. >> >> Some of the same known outstanding problems >> still occur: >> >> >> * core CodeAuditTest testCodeAudit >> * >> core LocalizationAuditTest testCodeAudit >> * >> core Php43CompatibilityTest >> testCodeAudit >> * core PhpDocAuditTest testCodeAudit >> * >> core SvnAuditTest testCodeAudit >> * >> core TemplateAuditTest testCodeAudit >> >> >> >> * "Test skipped: >> .svn/entries not found" >> >> >> * core IndexDotPhpTest testHttpRedirect >> >> >> >> * "Set-Cookie header not set:" >> >> >> * core StorageTest testEncodeDecodeBlob >> >> >> >> * "blob data was altered >> in encode -> insert -> select -> decode" >> >> >> * migrate >> ConfirmImportControllerTest testImportKOI_8 >> >> >> >> * "db2_exec() >> [function.db2-exec >> <http://cpe0013102da23b-cm0f0079804905.cpe.net.cable.rogers.co > m:800/Gallery2/lib/tools/phpunit/function.db2-exec> ]: Statement Execute > Failed in ?? > (PHPUnit_error_handler) at line ??" >> >> >> * migrate >> ConfirmImportControllerTest testConvertHtmlToBbcode >> >> >> >> * "There are unreleased locks" >> >> >> But there are also a few new failures (new >> since the last time I ran the unit tests): >> >> >> * DataCacheTest testCleanPageDataCache >> >> >> >> * "PHP ERROR: >> db2_fetch_array() [function.db2-fetch-array]: Cannot >> Determine LOB Size in ?? (PHPUnit_error_handler) at line ??" >> >> >> * ecard EcardControllerTest testSendEcard >> >> >> >> * "Error (ERROR_UNKNOWN) >> : Could not send mail to exa...@ex... >> <mailto:exa...@ex...> " >> * Generates a popup >> dialog box that contains only "1" and an "OK" button. >> >> >> * ecard EcardControllerTest >> testMaliciousContent >> >> >> >> * "Error (ERROR_UNKNOWN) >> : Could not send mail to su...@ex... >> <mailto:su...@ex...> >> >> >> * core SessionTest >> testLoadSessionDataExpiredSession >> >> >> >> * "creation time activity >> timeout, Mismatch At: [] 1162137436 !== 1162137437" >> >> >> I haven't investigated the new failures yet, >> but all of them are newer tests that have never before been >> run on DB2, and they all still fail even with the original >> STRING column sizes, so I think it's OK to make the change to >> STRING lengths for G2.2. >> >> Andy, will you be doing so, or would you like me to? >> -------------------- >> Larry Menard >> "Defender of Geese and of All Things Natural" >> E-mail and MSN Messenger: >> lar...@ro... <mailto:lar...@ro...> >> Web: >> http://ca.geocities.com/lar...@ro... >> <http://ca.geocities.com/lar...@ro...> >> >> >> ----- Original Message ----- >> From: "Larry Menard" <lar...@ro... >> <mailto:lar...@ro...> > >> To: <gal...@li... >> <mailto:gal...@li...> > >> Sent: Saturday, October 28, 2006 10:55 PM >> Subject: Re: [Gallery-devel] Alter all DB2 >> tables due to UTF8 character vs bytelength >> >> >> > Ah, OK, now I understand. >> > >> > I'll do a quick install tomorrow with the >> new STRING values (4x the >> > current values), and if that installs OK I >> say we go with it... it's a very >> > small change. >> > -------------------- >> > Larry Menard >> > "Defender of Geese and of All Things Natural" >> > E-mail and MSN Messenger: >> lar...@ro... <mailto:lar...@ro...> >> > Web: >> http://ca.geocities.com/lar...@ro... >> <http://ca.geocities.com/lar...@ro...> >> > >> > >> > ----- Original Message ----- >> > From: "Andy Staudacher" <an...@ee... >> <mailto:an...@ee...> > >> > To: <gal...@li... >> <mailto:gal...@li...> > >> > Sent: Saturday, October 28, 2006 11:21 PM >> > Subject: Re: [Gallery-devel] Alter all DB2 >> tables due to UTF8 >> > charactervsbytelength >> > >> > >> >> Problem: >> >> We can only store 128 byte in the DB2 >> STRING-MEDIUM fields (e.g. item >> >> title, >> >> summary, comment summary, ...). >> >> Other DBMS can store 128 characters in our >> varchar(128) (STRING-MEDIUM) >> >> fields. Not 128 bytes. >> >> For DB2, that means just 32 UTF8 multibyte >> characters in the worst case. >> >> That doesn't matter for most Americans, but >> for some international users >> >> that's reality. >> >> >> >> So I'm saying we need to change all table >> columns for DB2 of type >> >> STRING-(SMALL|MEDIUM|LARGE). >> >> SMALL becomes 4 * 32 bytes to guarantee that >> we can store 32 multibyte >> >> characters, MEDIUM becomes 4 * 128 bytes, etc. >> >> >> >> BTW: Right now, I have prepared a change >> that just truncates strings for >> >> DB2 >> >> using the byte count instead of the >> character count. We'll have that in >> >> place as long as we don't do the above change. >> >> >> >> I don't want to change the TEXT fields in this task. >> >> >> >> So let's say all STRING columns (not TEXT) >> are 4 times the size of what >> >> they >> >> have now. >> >>>From our definitions for TEXT columns in >> generate-sql, it looks like we >> >>>have >> >> some room left. No need to make them a >> little smaller. We can just change >> >> the size of the STRING columns. >> >> >> >> Do you agree with that assessment? >> >> >> >> - Andy >> >> >> >> Larry Menard wrote: >> >> [...] >> >>> Sorry, I don't quite follow what you're >> asking. Are you >> >>> saying that the VARCHAR fields are too small? >> >> [...] >> >>> Andy Staudacher wrote: >> >> [...] >> >>> > -> We need to change the DB2 definition >> of our STRING >> >>> columns to accommodate >> >>> > for the maximum possible byte length. So >> size * 4 = >> >>> 32*4=128, 128*4=512, >> >>> > 255*4=1020 > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > __[ g a l l e r y - d e v e l ]_________________________ > > [ list info/archive --> http://gallery.sf.net/lists.php ] > [ gallery info/FAQ/download --> http://gallery.sf.net ] |