Heh, yes, it does seem quite odd now that I think about it and read the code. Tell ya what... I'll get it working with the current versions, then you experts can place it where you THINK it should be... :) I imagine you will want to chop up the display class quite a bit, but I'm certainly not qualified to do it :) I'm certainly not ready for this yet, but who wants to test this stuff out once I think its at least fairly close to working? -----Original Message----- From: Gilles Detillieux [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 31, 1999 1:55 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [htdig3-dev] Re: searching by date range According to Geoff Hutchison: > On Wed, 31 Mar 1999, Gilles Detillieux wrote: > > I think a better place would be Display::buildMatchList(), because the > > DocTime() field is in the DocumentRef object, fetched from docDB in this > > function. No point fetching the record from the database more than once > > per match. > > I'm a bit concerned with the code bloat in Display.cc. I'd like to see > some of the code moved out of that file to more logical locations. My > initial assumptions (way back when) were that variable expansion was done > by the Template object, that sorting and filtering of results were done > either in htsearch.cc or ResultList, etc. I agree. I did find it odd that so much of htsearch's logic was in the Display class, rather than elsewhere, but in the interest of making additions as unobtrusive as possible, I never chose to reorganise anything. I was just pointing out to Mike where the existing methods are, but yeah, when you think about it, why is buildMatchList in Display.cc? > Of course, Gilles has a good point that it's better to fetch the record > only once, if possible. > > > (2^32-1) is Jan. 19, 2038, 03:14:07 UTC. This field will no doubt become > > a 64-bit integer before then. > > Some systems already have 64-bit dates. As usual, it's best to avoid > assumptions about the size of types. Absolutely. That's why I suggested a size independent way of calculating the maximum value. Please let me know if I got the formula wrong, but I think it'll work. > > for the end. This latter value will be the maximum signed value for a > > time_t, regardless of how many bytes it's eventually defined to be. > > True. Then again, shouldn't we be worried about documents published in the > future? Uhm, yeah. That's why the default end time for the allowed time range should be the maximum possible time_t. That way, if you don't specify the end year, month or day, there is effectively no upper limit to the date of documents included in the search results. The assumption is that time_t will always be large enough to accomodate dates the system will need to deal with. Right now, most (but not all) OSes have a 32-bit time_t. This will need to change before the late 2030s. A 64-bit time_t will last over a billion centuries, which should be adequate for our purposes. ;) -- Gilles R. Detillieux E-mail: <[EMAIL PROTECTED]> Spinal Cord Research Centre WWW: http://www.scrc.umanitoba.ca/~grdetil Dept. Physiology, U. of Manitoba Phone: (204)789-3766 Winnipeg, MB R3E 3J7 (Canada) Fax: (204)789-3930 ------------------------------------ To unsubscribe from the htdig3-dev mailing list, send a message to [EMAIL PROTECTED] containing the single word "unsubscribe" in the SUBJECT of the message. ------------------------------------ To unsubscribe from the htdig3-dev mailing list, send a message to [EMAIL PROTECTED] containing the single word "unsubscribe" in the SUBJECT of the message.
