Em skrev:
This is a really cool feature!
Thanks for pointing us in that direction!
A feature where you can flag your "index" operation to provide "create
sematics" would be cool. When setting the "create-semantics" flag, an
"index" operation will fail if a document with simular id (or whatever
you use for uniqueKey) already exist. When the flag is not set "index"
semantics will be just as it is today. ElasticSearch has this, except
that they call it "OpType" which has the possible values "create" and
"index" ("index" is default). Most other alternatives to Solr(Cloud)
provide this as well. We need it in my current project. We might make it
"outside" Solr/Lucene but I hope to be able to convince my ProductOwner
to make it as a Solr-feature contributing it back - especiallly if the
Solr community agrees that it would be a nice and commonly usable
feature. Believe it is a commonly usable feature - especially "when
using Solr as a NoSQL data store and not just a search index" (as
http://wiki.apache.org/solr/RealTimeGet says)
As the "Quick Start" says, a document does not need a commit nor a
soft-commit or anything else to be available via RealTimeGet.
However, regarding a versioning-system, one always has to keep in mind
that an uncommited document is not guaranteed to be persisted in the index.
So if you give a Duplicate-Key-Error, because there is a pending
document with that key and afterwards the server goes down for any
reason, you might end up without that document inside of Solr.
You need a log for failover.
Yes I know. Or you might just not consider a datarecord inserted into
Solr before it has been indexed AND a hard-commit has happened. You can
have many threads working on indexing datarecords into Solr but not
deleting/acknowledging the source for those datarecords before next
hard-commit has happend after index. But I believe it is another issue -
one we also have plans about dealing with.
Thanks everybody!
Kind regards,
Em
Am 24.02.2012 11:06, schrieb Per Steffensen:
Sami Siren skrev:
Given that you've set a uniqueKey-field and there already exists a
document with that uniqueKey, it will delete the old one and insert the
new one. There is really no difference between the semantics - updates
do not exist.
To create a UNIQUE-constraint as you know it from a database you
have to
check whether a document is already in the index *or* whether it is
already pending (waiting for getting flushed to the index).
Fortunately Solr manages a so called pending-set with all those
documents waiting for beeing flushed to disk (Solr 3.5).
We are using latest greates 4.0-SNAPSHOT code, because we want to take
advantage of SolrCloud stuff. Can you give a code-pointer to where I can
find the pending-set stuff?
I am not sure if this is what you're asking but you should be able to
get the latest data from Solr by using
realtime get http://wiki.apache.org/solr/RealTimeGet
Thanks a lot! I might be very usefull, if this provide 100% real time
get - that is, if it gets the latest version of the document, also when
neither a soft-commit nor a hard-commit has been performed since the
lastest version of the document was indexed. Does it do that, or does it
need a soft commit (then I believe it is only a near real time get
operation)?
--
Sami Siren
