Yonik Seeley wrote: > On 10/23/06, Paul Waite <[EMAIL PROTECTED]> wrote: > > However if I understand the above properly, we should implement a strategy > > which at least limits the commit frequency, to prevent the scenario you > > describe in the last para above. > > Right. If a new news item comes in, you could do a commit immediately and then > ensure that another commit is not done within "x" amount of time. > > Some ideas on features I've never had the chance to implement are > minimumCommitFrequency (like described above) and > auto commit (let solr decide when to commit... after x docs or y > seconds w/o a commit). > > I'd accept patches that baked any of that stuff into Solr :-) Yes, I was thinking along the same lines earlier when considering how best to implement it. Certainly the place for that processing is right inside Solr itself, because it's hard to drive the commit nicely from an external source when its kinda asynchronous like that. You have to maintain the state of the commit somewhere and generally external clients are in the 'use Solr then forget it until next time' sort of mode, and that's the way they should stay.
So I'll have a look at doing it certainly since it seems to be a requirement for my usage of Solr - don't expect it overnight though, as I only had my first 30 minutes look at the code yesterday. ;-) Cheers, Paul.
