Hi, On Tue, Jul 9, 2013 at 10:36 PM, Ed Kohlwey <[email protected]> wrote: > There's common indexing design patterns on top of some of these databases > where a deterministic hash is used as the primary key (in order to avoid > locking on an id incrementer, for instance, and to make the insert > operations idempotent).
OK, I better understand what you are trying to achieve. Lucene doc IDs are just a convenient way to communicate in-between internals APIs such as the inverted index and stored fields, but they are stored nowhere. Conceptually, they are like an index in an array: they uniquely identify an element in an array but aren't stored anywhere, you can think of the internal APIs as parallel arrays. And they are transient, when segment are merged, doc IDs change. I don't think it is possible to write a reasonably fast Lucene view on top of the existing index of your database, you would have to keep on translating the database doc IDs to Lucene doc IDs and this would likely kill performance. -- Adrien --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
