From: Kieran K. <kie...@ma...> - 2008-02-17 00:39:54
|
Just a heads up. There is a serious Wonder bug that manifests itself when making an EOOrQualifier on an array of multiple ERXBetweenQualifiers Here is an example of the toString of an EOOrQualifier made on an array of ERXBetweenQualifiers: ((sicCode between 600000 and 659999) or (sicCode between 729100 and 729199) or (sicCode between 737100 and 737999) or (sicCode between 750000 and 759999) or (sicCode between 799100 and 799199) or (sicCode between 800000 and 829999) or (sicCode between 872100 and 872199) or (sicCode between 701100 and 701199) or (sicCode = 275998) or (sicCode between 731100 and 731399) or (sicCode = 874213) or (sicCode between 581200 and 581299) or (sicCode = 874214) or (sicCode between 731900 and 731999)) Now here is the corresponding SQL generated in the WHERE segment of the SQL statement: AND t0.sic_code IN (731900, 874214, 581200, 874213, 731100, 275998, 701100, 872100, 800000, 799100, 750000, 737100, 729100, 600000) ... aaarrrrggggghhhhhh!!! I examined Wonder code and, though not sure why (and I am swamped doing damage-control due to this right now, so no time for more research just now), the root cause seems to lie with the ERXInOrQualifierSupport replacement of the standard EOOrQualifier support. Simply commenting out the following lines at around line 200 in ERXApplication solves the problem (I am on WO 5.3 and MySQL BTW). Can a committer please comment out in source until I or someone can get time to figure out exactly why this happens. // if (!ERXApplication.isWO54()) { // //AK: in 5.4 disable // EOQualifierSQLGeneration.Support.setSupportForClass(new ERXInOrQualifierSupport(), EOOrQualifier._CLASS); // } OK, got to run ..... must find orders that did not get their filled correctly, fix the database and re-run before start of business Monday am :-( |
From: Mike S. <ms...@md...> - 2008-02-17 00:46:13
|
It's because ERXBetweenQualifer extends ERXKeyValueQualifier, so it's tricking ERXInOrQualifier into thinking it can be represented as an in- query ... ms On Feb 16, 2008, at 7:39 PM, Kieran Kelleher wrote: > Just a heads up. There is a serious Wonder bug that manifests itself > when making an EOOrQualifier on an array of multiple > ERXBetweenQualifiers > > Here is an example of the toString of an EOOrQualifier made on an > array of ERXBetweenQualifiers: > > ((sicCode between 600000 and 659999) or (sicCode between 729100 and > 729199) or (sicCode between 737100 and 737999) or (sicCode between > 750000 and 759999) or (sicCode between 799100 and 799199) or > (sicCode between 800000 and 829999) or (sicCode between 872100 and > 872199) or (sicCode between 701100 and 701199) or (sicCode = 275998) > or (sicCode between 731100 and 731399) or (sicCode = 874213) or > (sicCode between 581200 and 581299) or (sicCode = 874214) or > (sicCode between 731900 and 731999)) > > > Now here is the corresponding SQL generated in the WHERE segment of > the SQL statement: > > AND t0.sic_code IN (731900, 874214, 581200, 874213, 731100, 275998, > 701100, 872100, 800000, 799100, 750000, 737100, 729100, 600000) > > ... aaarrrrggggghhhhhh!!! > > > I examined Wonder code and, though not sure why (and I am swamped > doing damage-control due to this right now, so no time for more > research just now), the root cause seems to lie with the > ERXInOrQualifierSupport replacement of the standard EOOrQualifier > support. Simply commenting out the following lines at around line > 200 in ERXApplication solves the problem (I am on WO 5.3 and MySQL > BTW). Can a committer please comment out in source until I or > someone can get time to figure out exactly why this happens. > > > // if (!ERXApplication.isWO54()) { > // //AK: in 5.4 disable > // EOQualifierSQLGeneration.Support.setSupportForClass(new > ERXInOrQualifierSupport(), EOOrQualifier._CLASS); > // } > > > OK, got to run ..... must find orders that did not get their filled > correctly, fix the database and re-run before start of business > Monday am :-( > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________________________________________ > Wonder-disc mailing list > Won...@li... > https://lists.sourceforge.net/lists/listinfo/wonder-disc |
From: Mike S. <ms...@md...> - 2008-02-17 00:53:55
|
This should be fixed now ... Seems kind of weird that ERXBetweenQ extends ERXKVQ in the first place, but who knows. ms On Feb 16, 2008, at 7:46 PM, Mike Schrag wrote: > It's because ERXBetweenQualifer extends ERXKeyValueQualifier, so > it's tricking ERXInOrQualifier into thinking it can be represented > as an in-query ... > > ms > > On Feb 16, 2008, at 7:39 PM, Kieran Kelleher wrote: > >> Just a heads up. There is a serious Wonder bug that manifests >> itself when making an EOOrQualifier on an array of multiple >> ERXBetweenQualifiers >> >> Here is an example of the toString of an EOOrQualifier made on an >> array of ERXBetweenQualifiers: >> >> ((sicCode between 600000 and 659999) or (sicCode between 729100 and >> 729199) or (sicCode between 737100 and 737999) or (sicCode between >> 750000 and 759999) or (sicCode between 799100 and 799199) or >> (sicCode between 800000 and 829999) or (sicCode between 872100 and >> 872199) or (sicCode between 701100 and 701199) or (sicCode = >> 275998) or (sicCode between 731100 and 731399) or (sicCode = >> 874213) or (sicCode between 581200 and 581299) or (sicCode = >> 874214) or (sicCode between 731900 and 731999)) >> >> >> Now here is the corresponding SQL generated in the WHERE segment of >> the SQL statement: >> >> AND t0.sic_code IN (731900, 874214, 581200, 874213, 731100, 275998, >> 701100, 872100, 800000, 799100, 750000, 737100, 729100, 600000) >> >> ... aaarrrrggggghhhhhh!!! >> >> >> I examined Wonder code and, though not sure why (and I am swamped >> doing damage-control due to this right now, so no time for more >> research just now), the root cause seems to lie with the >> ERXInOrQualifierSupport replacement of the standard EOOrQualifier >> support. Simply commenting out the following lines at around line >> 200 in ERXApplication solves the problem (I am on WO 5.3 and MySQL >> BTW). Can a committer please comment out in source until I or >> someone can get time to figure out exactly why this happens. >> >> >> // if (!ERXApplication.isWO54()) { >> // //AK: in 5.4 disable >> // EOQualifierSQLGeneration.Support.setSupportForClass(new >> ERXInOrQualifierSupport(), EOOrQualifier._CLASS); >> // } >> >> >> OK, got to run ..... must find orders that did not get their filled >> correctly, fix the database and re-run before start of business >> Monday am :-( >> >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2008. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________________________________________ >> Wonder-disc mailing list >> Won...@li... >> https://lists.sourceforge.net/lists/listinfo/wonder-disc > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________________________________________ > Wonder-disc mailing list > Won...@li... > https://lists.sourceforge.net/lists/listinfo/wonder-disc |
From: Kieran K. <kie...@ma...> - 2008-02-17 02:11:06
|
Thanks Mike ..... you are the best. I will validate this fix in my next Wonder update .......... for now I will stay with current stable Wonder source having EOOrInQualifierSupport disabled just to get production going again. Regards, Kieran On Feb 16, 2008, at 7:53 PM, Mike Schrag wrote: > This should be fixed now ... Seems kind of weird that ERXBetweenQ > extends ERXKVQ in the first place, but who knows. > > ms > > On Feb 16, 2008, at 7:46 PM, Mike Schrag wrote: > >> It's because ERXBetweenQualifer extends ERXKeyValueQualifier, so >> it's tricking ERXInOrQualifier into thinking it can be represented >> as an in-query ... >> >> ms >> >> On Feb 16, 2008, at 7:39 PM, Kieran Kelleher wrote: >> >>> Just a heads up. There is a serious Wonder bug that manifests >>> itself when making an EOOrQualifier on an array of multiple >>> ERXBetweenQualifiers >>> >>> Here is an example of the toString of an EOOrQualifier made on an >>> array of ERXBetweenQualifiers: >>> >>> ((sicCode between 600000 and 659999) or (sicCode between 729100 >>> and 729199) or (sicCode between 737100 and 737999) or (sicCode >>> between 750000 and 759999) or (sicCode between 799100 and 799199) >>> or (sicCode between 800000 and 829999) or (sicCode between 872100 >>> and 872199) or (sicCode between 701100 and 701199) or (sicCode = >>> 275998) or (sicCode between 731100 and 731399) or (sicCode = >>> 874213) or (sicCode between 581200 and 581299) or (sicCode = >>> 874214) or (sicCode between 731900 and 731999)) >>> >>> >>> Now here is the corresponding SQL generated in the WHERE segment >>> of the SQL statement: >>> >>> AND t0.sic_code IN (731900, 874214, 581200, 874213, 731100, >>> 275998, 701100, 872100, 800000, 799100, 750000, 737100, 729100, >>> 600000) >>> >>> ... aaarrrrggggghhhhhh!!! >>> >>> >>> I examined Wonder code and, though not sure why (and I am swamped >>> doing damage-control due to this right now, so no time for more >>> research just now), the root cause seems to lie with the >>> ERXInOrQualifierSupport replacement of the standard EOOrQualifier >>> support. Simply commenting out the following lines at around line >>> 200 in ERXApplication solves the problem (I am on WO 5.3 and >>> MySQL BTW). Can a committer please comment out in source until I >>> or someone can get time to figure out exactly why this happens. >>> >>> >>> // if (!ERXApplication.isWO54()) { >>> // //AK: in 5.4 disable >>> // EOQualifierSQLGeneration.Support.setSupportForClass(new >>> ERXInOrQualifierSupport(), EOOrQualifier._CLASS); >>> // } >>> >>> >>> OK, got to run ..... must find orders that did not get their >>> filled correctly, fix the database and re-run before start of >>> business Monday am :-( >>> >>> >>> -------------------------------------------------------------------- >>> ----- >>> This SF.net email is sponsored by: Microsoft >>> Defy all challenges. Microsoft(R) Visual Studio 2008. >>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>> _______________________________________________ >>> Wonder-disc mailing list >>> Won...@li... >>> https://lists.sourceforge.net/lists/listinfo/wonder-disc >> >> --------------------------------------------------------------------- >> ---- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2008. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> Wonder-disc mailing list >> Won...@li... >> https://lists.sourceforge.net/lists/listinfo/wonder-disc > > ---------------------------------------------------------------------- > --- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Wonder-disc mailing list > Won...@li... > https://lists.sourceforge.net/lists/listinfo/wonder-disc |
From: Kieran K. <kie...@ma...> - 2008-03-25 19:10:39
|
Just updated to a new version of Wonder and wanted to confirm that this is fixed. Thanks, Kieran On Feb 16, 2008, at 7:53 PM, Mike Schrag wrote: > This should be fixed now ... Seems kind of weird that ERXBetweenQ > extends ERXKVQ in the first place, but who knows. > > ms > > On Feb 16, 2008, at 7:46 PM, Mike Schrag wrote: > >> It's because ERXBetweenQualifer extends ERXKeyValueQualifier, so >> it's tricking ERXInOrQualifier into thinking it can be represented >> as an in-query ... >> >> ms >> >> On Feb 16, 2008, at 7:39 PM, Kieran Kelleher wrote: >> >>> Just a heads up. There is a serious Wonder bug that manifests >>> itself when making an EOOrQualifier on an array of multiple >>> ERXBetweenQualifiers >>> >>> Here is an example of the toString of an EOOrQualifier made on an >>> array of ERXBetweenQualifiers: >>> >>> ((sicCode between 600000 and 659999) or (sicCode between 729100 >>> and 729199) or (sicCode between 737100 and 737999) or (sicCode >>> between 750000 and 759999) or (sicCode between 799100 and 799199) >>> or (sicCode between 800000 and 829999) or (sicCode between 872100 >>> and 872199) or (sicCode between 701100 and 701199) or (sicCode = >>> 275998) or (sicCode between 731100 and 731399) or (sicCode = >>> 874213) or (sicCode between 581200 and 581299) or (sicCode = >>> 874214) or (sicCode between 731900 and 731999)) >>> >>> >>> Now here is the corresponding SQL generated in the WHERE segment >>> of the SQL statement: >>> >>> AND t0.sic_code IN (731900, 874214, 581200, 874213, 731100, >>> 275998, 701100, 872100, 800000, 799100, 750000, 737100, 729100, >>> 600000) >>> >>> ... aaarrrrggggghhhhhh!!! >>> >>> >>> I examined Wonder code and, though not sure why (and I am swamped >>> doing damage-control due to this right now, so no time for more >>> research just now), the root cause seems to lie with the >>> ERXInOrQualifierSupport replacement of the standard EOOrQualifier >>> support. Simply commenting out the following lines at around line >>> 200 in ERXApplication solves the problem (I am on WO 5.3 and MySQL >>> BTW). Can a committer please comment out in source until I or >>> someone can get time to figure out exactly why this happens. >>> >>> >>> // if (!ERXApplication.isWO54()) { >>> // //AK: in 5.4 disable >>> // EOQualifierSQLGeneration.Support.setSupportForClass(new >>> ERXInOrQualifierSupport(), EOOrQualifier._CLASS); >>> // } >>> >>> >>> OK, got to run ..... must find orders that did not get their >>> filled correctly, fix the database and re-run before start of >>> business Monday am :-( >>> >>> >>> ------------------------------------------------------------------------- >>> This SF.net email is sponsored by: Microsoft >>> Defy all challenges. Microsoft(R) Visual Studio 2008. >>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________________________________________ >>> Wonder-disc mailing list >>> Won...@li... >>> https://lists.sourceforge.net/lists/listinfo/wonder-disc >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2008. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________________________________________ >> Wonder-disc mailing list >> Won...@li... >> https://lists.sourceforge.net/lists/listinfo/wonder-disc > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________________________________________ > Wonder-disc mailing list > Won...@li... > https://lists.sourceforge.net/lists/listinfo/wonder-disc |