Sorry, you have completely lost me :/ In simple terms, there are times when you want the primary storage (database) and the Lucene index to be in synch - and updated atomically. It all depends on the kind of application.
-N -----Original Message----- From: Fuad Efendi [mailto:f...@efendi.ca] Sent: 25 January 2010 16:06 To: solr-user@lucene.apache.org Subject: RE: Solr vs. Compass > >> Why to embed "indexing" as a transaction dependency? Extremely > >> weird > idea. > There is nothing weird about different use cases requiring different > approaches.... > > If you're just thinking documents and text search ... then its less of > an issue. > If you have an online application where the indexing is being used to > drive certain features (not just search), then the transactionality is > quite useful. I mean: - Primary Key Constraint in RDBMS is not the same as an index - Index in RDBMS: data is still searchable, even if we don't have index Are you sure that index in RDBMS is part of transaction in current implementations of Oracle, IBM, SUN? I never heard such staff, there are no such requirements for transactions. I am talking about transactions and referential integrity, and not about indexed non-tokenized single-valued field "Social Insurance Number". It could be done asynchronously outside of transaction, I can't imagine use case when it must be done inside transaction / failing transaction when it can't be done. "Primary Key Constraint" is different use case, it is not necessarily indexing of data. Especially for Hibernate where we mostly use surrogate auto-generated keys. -Fuad =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================
