lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Woodward <>
Subject Re: Updateable DocValues
Date Wed, 25 Jul 2012 15:35:09 GMT
Hi Simon,

That sounds like a good place to start - I'll have a play with FieldNormUpdater and see if
I can hack it into something basic that works, and then open a JIRA.


On 25 Jul 2012, at 15:03, Simon Willnauer wrote:

> hey alan,
> On Wed, Jul 25, 2012 at 11:15 AM, Alan Woodward
> <> wrote:
>> Hi all,
>> I'm looking at implementing some fairly hairy ACLs using Solr post-filtering functionality,
storing the ACL information in DocValues for quick lookup.  Some of this information will
need to change frequently.  When DocValues were first announced a while back, it was suggested
that they could be 'independently updateable' - i.e. you could make changes to them without
reindexing the whole document.  I've been nosing around the code, and haven't found anything
that looks like an update API though.  Has this actually been implemented?  Or if not, how
tricky would it be to implement, given the existing implementation?  I'm guessing it would
need to be done via Codecs.
> this has not been implemented so far. I believe that the best way of
> implementing this is a stacked segment that we can write on top of an
> existing one and that would be merged once the segment is merged. We
> have talked about this for a long time but never actually got to the
> point to implement it. I think I will get to this once the position
> iterators are merged into trunk but if you wanna give it a shot ahead
> of time I am totally up for pairing and branching etc. There are a lot
> of interesting problems to solve like how to deal with merges and
> deleted docs while indexing etc. I was thinking of a update tool as a
> start that would work just like updateing norms in 3.6 were you close
> the IW, lock the index and update your docvalues, close the updater
> and open a writer again. That could be a good start with limited
> functionality but we can sketch out the underlying stuff before we
> deal with concurrent updates etc.
> what do you think, would that work for you?
> simon
>> Thanks,
>> Alan Woodward
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message