ou to turn on this behaviour of having "database" (RDBMS)
semantics, and when you do you get both.
Tomorrrow will create another Jira issue on the "versioning/optimistic
locking" part.
Per Steffensen skrev:
Hi
Does solr/lucene provide any mechanism for "unique key c
n on
this behaviour of having "database" (RDBMS) semantics, and when you do
you get both.
Tomorrrow will create another Jira issue on the "versioning/optimistic
locking" part.
Per Steffensen skrev:
Hi
Does solr/lucene provide any mechanism for "unique key constraint&qu
On Feb 24, 2012, at 6:55 AM, Em wrote:
> You need a log for failover.
There is a transaction log.
- Mark Miller
lucidimagination.com
Yonik,
thanks for sharing deeper details about how SolrCloud is going to work.
Do you plan to release any wiki-updates about the small details, so that
other developers are able to get in touch with what you've already done
there?
I think small guides and the mentioning of class-names and their
r
Hi Per,
if you are evaluating with your ProductOwner whether he/she wants to
contribute back:
Try to not see it only as a gift to the community for a highly usefull
product, but also see it as a protection of your investment.
What you are going to customize will be deeply integrated in Solr - in
On Fri, Feb 24, 2012 at 8:59 AM, Per Steffensen wrote:
> 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.
Per Steffensen skrev:
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 wit
Yonik Seeley skrev:
On Fri, Feb 24, 2012 at 9:04 AM, Per Steffensen wrote:
Cool. We have a test doing exactly that - indexing 2000 documents into Solr,
kill-9'ing Solr in the middle of the process, starting Solr again and
checking that 2000 documents will eventually be searchable. It lights
On Fri, Feb 24, 2012 at 9:04 AM, Per Steffensen wrote:
> Cool. We have a test doing exactly that - indexing 2000 documents into Solr,
> kill-9'ing Solr in the middle of the process, starting Solr again and
> checking that 2000 documents will eventually be searchable. It lights red as
> it is right
Yonik Seeley skrev:
On Fri, Feb 24, 2012 at 6:55 AM, Em wrote:
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.
We now have durability via an update log.
With a recent nightly trunk build
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 whatev
On Fri, Feb 24, 2012 at 6:55 AM, Em wrote:
> 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.
We now have durability via an update log.
With a recent nightly trunk build, you can send a document to
This is a really cool feature!
Thanks for pointing us in that direction!
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 docum
Hi Per,
> Can you give a code-pointer to where I can find the pending-set stuff?
> Does solr use this pending-set for query responses, so that solr deliver
> 100% real-time search results?
As of Solr 3.5 it can be found within the DirectUpdateHandler and
DirectUpdateHandler2-classes.
I am currentl
On Fri, Feb 24, 2012 at 12:06 PM, Per Steffensen wrote:
> 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 - upd
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 dat
>> 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
Em skrev:
Hi Per,
I want an error to occur if a document with the same id already
exists, when my intent is to INSERT a new document. When my intent is
to UPDATE a document in solr/lucene I want the old document already
in solr/lucene deleted and the new version of this document added
(exact
Hi Per,
> I want an error to occur if a document with the same id already
> exists, when my intent is to INSERT a new document. When my intent is
> to UPDATE a document in solr/lucene I want the old document already
> in solr/lucene deleted and the new version of this document added
> (exactly as
Per:
Yep, you've got it. You could write a custom update handler that queried
(via TermDocs or something) for the ID when your intent was to
INSERT, but it'll have to be custom work. I suppose you could query
with a divide-and-conquer approach, that is query for
id:(1 2 58 90... all your insert ID
Em skrev:
Hi Per,
well, Solr has no "Update"-Method like a RDBMS. It is a re-insert of the
whole document. Therefore a document with an existing UniqueKey marks
the old document as deleted and inserts the new one.
Yes I understand. But it is not always what I want to acheive. I want an
error
.
>>
>> Kind regards,
>> Em
>>
>> Am 21.02.2012 13:50, schrieb Per Steffensen:
>>
>>> Hi
>>>
>>> Does solr/lucene provide any mechanism for "unique key constraint" and
>>> "optimistic locking (versioning)"?
&g
n mind concurrent
updates).
Kind regards,
Em
Am 21.02.2012 13:50, schrieb Per Steffensen:
Hi
Does solr/lucene provide any mechanism for "unique key constraint" and
"optimistic locking (versioning)"?
Unique key constraint: That a client will not succeed creating a new
documen
Per Steffensen skrev:
Thanks a lot. We will use the UniqueKey feature and build versioning
ourselves. Do you think it would be a good idea if we built a
versioning feature into Solr/Lucene instead of doing it outside, so
that others can benefit from the feature as well? Guess contributions
wil
21.02.2012 13:50, schrieb Per Steffensen:
Hi
Does solr/lucene provide any mechanism for "unique key constraint" and
"optimistic locking (versioning)"?
Unique key constraint: That a client will not succeed creating a new
document in solr/lucene if a document already exists havin
ou have to do the versioning on your own (and keep in mind concurrent
updates).
Kind regards,
Em
Am 21.02.2012 13:50, schrieb Per Steffensen:
> Hi
>
> Does solr/lucene provide any mechanism for "unique key constraint" and
> "optimistic locking (versioning)"?
&g
Hi
Does solr/lucene provide any mechanism for "unique key constraint" and
"optimistic locking (versioning)"?
Unique key constraint: That a client will not succeed creating a new
document in solr/lucene if a document already exists having the same
value in some field (e
27 matches
Mail list logo
