Hi Geoffrey,
I'm on the road right now but I'd like to make some suggestions after I
gather my thoughts and get over my jet lag. I think that it is
definitely possible to hook into the query processing layer in order to
fork the tuple stream so that a listener process can populate the Lucene
indexes. I think that scraping the replication log stream would raise a
lot of issues around when work is really committed vs. when savepoints
are rolled back, and I would recommend against that approach.
Regards,
-Rick
Geoffrey Hendrey wrote:
Ok, well on to plan B then. Is there some stage in the preparation of inserts,
updates, and deletes at which the logical identity of a row is established?
That could be a good place to provide a lucene hook, or a more general
interceptor.
On Mar 18, 2009, at 6:55 AM, Jørgen Løland <[email protected]> wrote:
Geoff hendrey wrote:
I've been folowing knuts pointers and reading the docs on the classes that
marshal themselves over the wire via their writeObject method.
So, question about this:
"Type=update, Table=employee, Page=4321, Index=4, field 3=50000"
Does the page and index, collectively, constitute a "row ID".
If it is always a constant, than these three field are sufficient to
permanently identify the row, and we can use that information to consititute a
document ID in lucene.
It's constant until the record is moved to another page (which means "no",
really).
