Hi pugdog,
It works the following way:
$offset=0; # Logic Bug : should be set to 1
$limit=100; # Number of results to handle in one loop
...
The main logic is to keep memory usage low. $limit=100; is used to define how many categorys are loaded to memory and stored in the array to be built. If you set it to low it will increase your building time because you have to query the database to often. In nph-build.cgi the number of SQL querys = (Number of Categorys) / ($limit).
In your solution you set $limit= number of categorys. This means the whole recordset with all categories are loaded to memory. When you have many categories you will get memory errors. (Im not shure when perl gives up. But every programming language has its definitions of the maximum size of an array or hash)
WHILE(1) # will always be TRUE
$categories_r = $CATDB->query ( { ID => '*', mh => $limit, nh => $offset+1,.... # should be $offset,
# selects all categorys LIMIT ($offset * $limit), $limit
# see DBSQL.pm sub query
# and returns $limit categorys to work with in the next foreach loop
$offset++;
# increments lets call it the page counter
# in DBSQL.pm $offset (nh) gets multiplied with $limit (mh)
# # First let's see how many hits we got.
my ($offset, $table, $query);
$offset = ($nh -1) * $maxhits;
last unless... # quit loop if no results
I think this could be the problem of some users
im MySQL if the LIMIT statement is defined:
"The LIMIT clause can be used to constrain the number of rows returned by the SELECT statement. LIMIT takes one or two numeric arguments. If two arguments are given, the first specifies the offset of the first row to return, the second specifies the maximum number of rows to return. The offset of the initial row is 0 (not 1)."
Now what I didn't find is the reaction of MySQL if the offset exeeds the number of rows. Maybe older versions of MySQL asume 0 if an invalid value (>maxrows) is given.
This would be an explanation for the endless loop. It works fine however with my version.
To check this it would be nice if some user with the endless-loop problem could use their SQL-monitor in admin and try following statement:
SELECT * FROM Category LIMIT "Offset", 100
"Offset should be replaced with a number larger than the number of categorys.
A solution for users having problems with the endless-loop would be
check the number of categorys
insert an internal counter
exit the loop if the counter exeeds the num of cats
I hope it helps,
regards, alexander
It works the following way:
$offset=0; # Logic Bug : should be set to 1
$limit=100; # Number of results to handle in one loop
...
The main logic is to keep memory usage low. $limit=100; is used to define how many categorys are loaded to memory and stored in the array to be built. If you set it to low it will increase your building time because you have to query the database to often. In nph-build.cgi the number of SQL querys = (Number of Categorys) / ($limit).
In your solution you set $limit= number of categorys. This means the whole recordset with all categories are loaded to memory. When you have many categories you will get memory errors. (Im not shure when perl gives up. But every programming language has its definitions of the maximum size of an array or hash)
WHILE(1) # will always be TRUE
$categories_r = $CATDB->query ( { ID => '*', mh => $limit, nh => $offset+1,.... # should be $offset,
# selects all categorys LIMIT ($offset * $limit), $limit
# see DBSQL.pm sub query
# and returns $limit categorys to work with in the next foreach loop
$offset++;
# increments lets call it the page counter
# in DBSQL.pm $offset (nh) gets multiplied with $limit (mh)
# # First let's see how many hits we got.
my ($offset, $table, $query);
$offset = ($nh -1) * $maxhits;
last unless... # quit loop if no results
I think this could be the problem of some users
im MySQL if the LIMIT statement is defined:
"The LIMIT clause can be used to constrain the number of rows returned by the SELECT statement. LIMIT takes one or two numeric arguments. If two arguments are given, the first specifies the offset of the first row to return, the second specifies the maximum number of rows to return. The offset of the initial row is 0 (not 1)."
Now what I didn't find is the reaction of MySQL if the offset exeeds the number of rows. Maybe older versions of MySQL asume 0 if an invalid value (>maxrows) is given.
This would be an explanation for the endless loop. It works fine however with my version.
To check this it would be nice if some user with the endless-loop problem could use their SQL-monitor in admin and try following statement:
SELECT * FROM Category LIMIT "Offset", 100
"Offset should be replaced with a number larger than the number of categorys.
A solution for users having problems with the endless-loop would be
check the number of categorys
insert an internal counter
exit the loop if the counter exeeds the num of cats
I hope it helps,
regards, alexander