> >> 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
