FW: Browse lookup - odd behavior

[Jay R. Ashworth]

On Fri, Jul 16, 2004 at 02:22:52AM -0400, John Esak wrote:
> > > > > And what would you cache instead?
> > > >
> > > > Whatever "lookup" information was use to generate the lookup in the
> > > > fisrt place, modulo whatever row-count offset has been generates by
> > > > user navigation.  That wasn't obvious?
> > >
> > > What about records that have been added/deleted since the
> > lookup was last
> > > run?  Starting at the 37th record is no longer a valid place to start.
> > >
> > > And what about keeping track of dropped records?
> > >
> > > Or are you suggesting actually re-running the lookup in its entirety?
> >
> > Doing anything else seems semantically inadequate, as this problem
> > demonstrates.
> 
> No, the problem demonstrates once again that there is a simple and "proper"
> method for writing this code so that the problem would never occur in the
> first place. Trying to have the browse window which already has "set"
> criteria determine what to do after it gathers "valid" records is not
> realistic. That is one excellent reason for the existence of the prc stub.
> In fact, one of its original intended functions. Having it written into the
> lookup line is not a good idea, not when considering the browse window may
> be displaying records in reverse order (descending) on an index which itself
> may be in descending order, the position of the highlight, the size of
> window, the size of file (in records), etc., etc. Not at least to do this
> all efficiently and without re-reading-executing the entire lookup as you
> are suggesting. The browse will match the original criteria, and by simply
> adding a  "DROP" for any record not matching the specified key, the problem
> disappears. I suggested this solution to Richard in the FP Room before he
> talked with FP Tech. Without knowing or thinking too long about why the
> problem was happening, it was not difficult to suggest a good method for
> coding that would eliminate it.
> 
> In most cases, one will not be deleting _and_ re-using the records in any
> particular browse lookup. If, the browse being written does look into a file
> that may be being updated simultaneously by other users, then adding the
> DROP is not only no big deal, but a required addition to the browse
> construction as filePro is now implementing it.

Well, that's all fine, John... but is that really the only reason he's
deleteing the lookup records?  If he really wants them *gone*, then
pretty clearly, just doing a DROP isn't going to help him much.

> As always, I take issue with your always immediate evaluation that whatever
> being discussed is a "bad design" decision, especially when your instant-fix
> suggestions are always far short of the mark in their scope and actual
> usability. Send up some code for a browse that works better than filePro's
> does next time, rather than the usual flip response of "I could do it
> better, and isn't it obvious?"... when you really can't... and more people
> might take your suggestions seriously.

We were no longer discussing his specific case, except as a pedagogical
example.  I stand by my assertion.  If a browse lookup is done on index
keys, and it internally caches record numbers heedless of the fact that
other things may externally change them and cause them to no longer be
part of the semantically defined lookup, then the lookup code is Broken
As Designed.

Hope you didn't injure your knee on the desk, there, John.  :-)

Cheers,
-- jra
-- 
Jay R. Ashworth                                                jra at baylink.com
Designer                          Baylink                             RFC 2100
Ashworth & Associates        The Things I Think                        '87 e24
St Petersburg FL USA      http://baylink.pitas.com             +1 727 647 1274

	"You know: I'm a fan of photosynthesis as much as the next guy,
	but if God merely wanted us to smell the flowers, he wouldn't 
	have invented a 3GHz microprocessor and a 3D graphics board."
					-- Luke Girardi