Demand Indexes and deleting records.

[Fairlight]

I've never used the infernal things.  I know at least one other person
who does, but...I wouldn't.

That said, not sure they're -quite- unusable as you make it seem.

Imagene watcher running on your keys and paying attention to CoW, with
the ability to rebuild the indexes as it sees the keys being altered.
Also imagine that the program which actually rebuilds them acts as a
multi-modal programme which not only handles the locking, but gives
flock() clearance for actually ensuring that they're usable, and you
use it to ensure integrity.

It's conceivably doable, but really bloody cumbersome, with a tonne of
sanity checking required to be absolutely ensured, and they'd be running
very inefficiently.

m->


On Mon, Dec 14, 2020 at 09:55:09PM -0500, Brian K. White via Filepro-list thus spoke:
> On 12/14/20 1:26 PM, Scott Walker via Filepro-list wrote,
> > In my mind that would make Demand indexes totally unusable on any system with more than one user, and maybe not even then.
> 
> Agreed. I never used them. Even a single-user system is not a single-process
> system.
> 
> I think the feature is only good for setting up non-trivial searches based
> on things you don't have automatic indexes for already, and where it's not
> important if it's 100% correct. Actually, because of what I'll point out
> later, it needs to be ok if it's wildly not even remotely close, let alone
> 100%.
> 
> No definitive reports for accounting, no actionable business logic like what
> you described or like automatic inventory replenishment or really anything
> important, but maybe useful to get a rough answer about something. I never
> found any such situation that wasn't solved by just using the most
> appropriate auto index and filtering the rest of the way in processing, but
> maybe they exist.
> 
> Main reason I never used them is actually even simpler than this, which was
> just that it's effectively a temp file in a shared, non-temp, non-unique
> path and filename. If the generated index file was
> /tmp/foo_${REALLY_UNIQUE}, then ok, but it's the same /path/to/foo/index.4
> for all other processes on the system. (Well, all other processes using the
> same PFDATA+PFDIR) Utterly un-usable outside of ms-dos or earlier.
> 
> By unusable, I don't mean it's impossible to try to rig up some sort of
> locking scheme, I mean it's wrong to even try. You can't ever actually count
> on something like that. "all my programs know to check for X before
> touching, and I'm the only developer..." Right. Ok. Is the rule enforced by
> the kernel or by the fp binaries? I didn't think so, and so, no.
> 
> All that said, maybe it could be hacked to work. The unique temp file aspect
> I mean.  Maybe you could generate a random unique temp qualifier and use
> that just for the demand index? I never tried and I don't know off the top
> of my head if it's possible or maybe possible but just impractical.
> 
> -- 
> bkw
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> Subscribe/Unsubscribe/Subscription Changes
> http://mailman.celestial.com/mailman/listinfo/filepro-list
> 

-- 
Audio panton, cogito singularis.