1) Given the basics of the sorting (structure is in $cvsQ):
...the table names appear in pairs $a and $b and the sort routine needs access to $obj to compare the CSV data for the two tables. When I tried passing parameters to the sort routine or putting $obj-> in front of the sort routine call, I got a syntax error. But when I removed the $obj-> from the call, this corrected the syntax error. But strangely, the code below which shifts the first parameter magically DWIMmed by getting the right object...$obj->_getset('csvQ', $csvQ); for my $csvq ( sort _DBsort4create keys %$csvQ ) { $obj->_getset('ar', $csvq); $obj->_arr2db; # create and populate table }
the above code therefore displayed a dump of the AoA for the first key about to be sorted in the HoAoA. So how did it acquire $obj as a parameter given that the sort routine is called bare? There is a CPAN module that provides a sort routine for objects but that isn't the same thing at all. I could pass the structure via a package variable but then I haved two evils to choose from: global variables versus undocumented features.sub _DBsort4create { my $obj = shift; my $csvref = $obj->_getset('csvQ'); die Dumper( $csvref->{$a} ); # next steps: 1) check for comparison already done # 2) if so just return old result # 3) get FK declaration, store implied # comparison unless contradicts history # if contradiction, give message that database design cannot be physically implemented }
2) If $a does not reference $b or vice versa, I can return 0 otherwise I can optimise by retrieving a previous comparison of the same pair before delving into the structure if already compared. But the problem is that there could be circular references that cannot be pairwise detected which one would expect to cause sort to go into an infinite loop. So the second issue is: given the list of established pairwise comparisons, how to test for an implied contradiction with the current iteration of sort e.g. M > N and N > P but one of the current pair declares P > M and so would cause an infinite loop if the sort routine were allowed to continue. And of course this suggests I need to do something other than pairwise sort in the first place.
The best idea I have is to build the history of comparisons as a list of groups (hashes) of comparisons instead of a list of comparisons, so that elements not explicitly sorted are left unsorted in each hash and the criteria for predicting an infinite loop becomes an attempt to put the same table in more than one group. Or perhaps someone has a less esoteric way to perform the test?
Many thanks!
Simon
One world, one people
In reply to Sort mechanics problems with objects and potentially contradicting comparisons (would cause infinite loop) by anonymized user 468275
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |