[ic] Problem with "Others who........" (resend in hope of
an answer this time)
Eros Shop
info at eros-shop.co.uk
Sat Mar 13 15:55:53 EST 2004
At 12:39 13/03/2004, you wrote:
>Hi Everyone,
>
>OK so my first post of this problem was _completely_ ignored, so I'm
>trying again.
>
>Please note that I am happy to provide any extra information if it will help
>
>I seem to be having a strange problem with the "Generate Others Who...."
>link on the merchandising page in the UI for 4.8.7 in that it seems to
>stop after processing 50 orders/orderlines :(
>
>The error log is less than helpful:
>
>supercow.vwe.net SpIKgoQC:vwe.net - [11/March/2004:12:20:28 +0000] eros
>/cgi-bin/eros/admin/build_related.html Error saving matches:
>
>Yup that's it, doesn't say what the error is just that there is one :(
>
>I've fiddled with the build_related.html to print out what's going on
>whilst it's working
>
>The page claims to be using this select statement:
>
> select code,order_number,sku,username from orderline
>
>I then have it print out the order numbers it finds, which looks like this:
>
>EROS00000124:
>EROS00000264:
>EROS00000029:
>EROS00000089:
>EROS00000008:
>EROS00000148:
>EROS00000221:
>EROS00000073:
>EROS00000207:
>EROS00000228:
>EROS00000289:
>EROS00000301:
>EROS00000178:
>EROS00000251:
>EROS00000037:
>EROS00000097:
>EROS00000076:
>EROS00000110:
>EROS00000170:
>EROS00000302:
>EROS00000215:
>EROS00000348:
>EROS00000356:
>EROS00000369:
>EROS00000370:
>EROS00000373:
>EROS00000312:
>EROS00000164:
>EROS00000023:
>EROS00000143:
>EROS00000062:
>EROS00000269:
>EROS00000283:
>EROS00000128:
>EROS00000087:
>EROS00000201:
>EROS00000261:
>EROS00000342:
>EROS00000367:
>EROS00000078:
>EROS00000306:
>EROS00000291:
>EROS00000010:
>EROS00000077:
>EROS00000150:
>EROS00000196:
>EROS00000255:
>EROS00000369:
>EROS00000207:
>EROS00000353:
>
>353 is the 50th line in the orderline DB that it encounters ( i know this
>to be the case as I've exported it and loaded it into excel to see which
>order things happen in and these two lists match up exactly) and then for
>no fathomable reason the process stops and immediately goes on to show the
>normal results you'd expect to see if it were working properly with only
>50 order lines....
>
>000005: times ordered=1 others_bought ==> {}
>000007: times ordered=2 others_bought ==> {}
>000045: times ordered=2 others_bought ==> {}
>000047: times ordered=1 others_bought ==> {}
>000051: times ordered=1 others_bought ==> {}
>000065: times ordered=1 others_bought ==> {}
>000067: times ordered=1 others_bought ==> {}
>000073: times ordered=1 others_bought ==> {}
>000087: times ordered=1 others_bought ==> {}
>000101: times ordered=3 others_bought ==> {}
>000103: times ordered=2 others_bought ==> {}
>000107: times ordered=1 others_bought ==> {}
>000111: times ordered=1 others_bought ==> {}
>000117: times ordered=1 others_bought ==> {}
>000123: times ordered=1 others_bought ==> {}
>000129: times ordered=4 others_bought ==> {}
>000145: times ordered=1 others_bought ==> {}
>000165: times ordered=8 others_bought ==> {}
>000183: times ordered=1 others_bought ==> {}
>000185: times ordered=1 others_bought ==> {}
>000187: times ordered=1 others_bought ==> {}
>000189: times ordered=1 others_bought ==> {}
>000191: times ordered=1 others_bought ==> {}
>000199: times ordered=1 others_bought ==> {}
>000217: times ordered=1 others_bought ==> {'000225' => "1",}
>000225: times ordered=1 others_bought ==> {'000217' => "1",}
>000241: times ordered=1 others_bought ==> {}
>000271: times ordered=2 others_bought ==> {}
>000319: times ordered=1 others_bought ==> {'000363' => "1",}
>000321: times ordered=1 others_bought ==> {}
>000363: times ordered=2 others_bought ==> {'000319' => "1",}
>000379: times ordered=2 others_bought ==> {}
>
>The problem is that i have 630 order lines so far spread across 373
>orders. It doesn't take a genius to work out that there's a LOT of stuff
>not being processed here, but I'm stumped as to how to fix it.
>
>I did find a couple of lines in orderline that didn't have a username, so
>I fixed that up hoping it was the answer but sadly it's made no difference
>at all.
>
>The code from build_related.html is as follows (it is untouched, except
>for the extra log lines I've added):
>
>[perl tables="__UI_META_TABLE__ orderline merchandising"]
> my $db = $Db{orderline};
> return "NO ORDERLINE table???!" if ! $db;
> my $start = tag_data( qw/__UI_META_TABLE__ lookup_exclude
> orderline/ );
>
> my $query = "select code,order_number,sku,username from orderline";
> if($start) {
> $query .= " where order_number > '$start'";
> }
> else {
> %sku = ();
> }
>
> my %on; # Keep track by order number
> my %un; # Keep track by username
> my %times_ordered; # Keep track by sku
>
> my $ary = $db->query( { sql => $query } );
>
># added by Mark
># $out .= "$query<br>\n";
>
> for(@$ary) {
> my ($line, $on, $sku, $un) = @$_;
> push @{$un{$un} ||= []}, $sku;
>
># added by Mark
># $out .= "$line:<br>\n";
># $out .= "$on:<br>\n";
># $out .= "$sku:<br>\n";
># $out .= "$on:<br>\n";
>
> $times_ordered{$sku}++;
> }
> for(keys %un) {
> my $ref = $un{$_};
> @ary = @$ref;
> for(@ary) {
> my $sku = $_;
> $sku{$sku} = {} unless $sku{$sku};
> for (@ary) {
> next if $_ eq $sku;
> $sku{$sku}->{$_}++;
> }
> }
> }
> my $mdb = $Db{merchandising};
> for(sort keys %sku) {
> my $val = $Tag->uneval( { ref => $sku{$_} } );
> $out .= "$_: times ordered=$times_ordered{$_}
> others_bought ==> $val<br>\n";
> $mdb->set_field($_, 'others_bought', $val );
> $mdb->set_field($_, 'times_ordered', $times_ordered{$_} );
> }
> return $out;
>[/perl]
>
>Does anyone have any ideas why this isn't working in the way it should?
>I'm feeling that something is wrong in the orderline DB, yet I'm not able
>to find it. It's that or I'm hitting some kind of limit, but I'm not able
>to find that as a setting/default either :(
>
>In the mean time I am manually entering stuff into the merchandising table
>for each order we process. This is very laborious and I would like to take
>advantage of the supplied link so that my time can be better spent on
>other things.
>
>My ideal solution to this problem would be to use an external perl script
>on a cron job that updates the merchandising table/txt file, but I'm happy
>to click the link a few times per week if needs be until a better solution
>can be found :)
>
>Anyway, I've had a good root about in the archives on google and sadly all
>the issues I found seemed to be related to permissions problems or
>excluding canceled order, which don't apply here.
>
>I'm sure this has to be something silly/simple!
>
>Many thanks in advance for any suggestions/help
>
>Mark
>
>P.S. At worst, I'm prepared to pay someone to solve this problem (and
>implement it) and will consider any serious and reasonable offers.
After grep'ing for "50" in all interchange files, in the hope of finding
some setting or value that may have some bearing on this mystery, I found
the following in DbSearch.pm in /usr/lib/interchange/lib/Vend/
my %Default = (
matches => 0,
mv_head_skip => 0,
mv_index_delim => "\t",
mv_matchlimit => 50,
mv_min_string => 1,
verbatim_columns => 1,
);
Could the element "mv_matchlimit => 50" be the magic number 50 that's
haunting me?
I'm not clever enough with Perl to understand how this value is being used
or when it comes into play, but could someone who does understand this
(possibly Mike :)) explain what impact changing it to a larger number would
have and if it will solve my problem?
Many thanks in advance
Mark
Eros Shop
vwe internet ltd
PO BOX 1067
SLOUGH
SL1 7YA
UK
Shop - http://www.eros-shop.co.uk
EMail - info at eros-shop.co.uk
Tel - 0870 737 3369
Fax - 0870 737 4469
More information about the interchange-users
mailing list