ersion_l field in the "new" document is not greater then the
> > >> value
> > >> > of that field in the existing document.*
> > >> >
> > >> > Do you have any tip on how to get same versions not getting
> rejected.
> >
> of that field in the existing document.*
> >> >
> >> > Do you have any tip on how to get same versions not getting rejected.
> >> >
> >> > Thanks a lot.
> >> >
> >> >
> >> > On 1 June 2017 at 19:04, Susheel K
pdate the document exactly as per the wiki
>> >> documentation.
>> >>
>> >> Thanks,
>> >> Susheel
>> >>
>> >> On Thu, Jun 1, 2017 at 7:57 AM, marotosg <marot...@gmail.com> wrote:
>> >>
>> >> > Thanks a lot Susheel.
>> >> > I see this is actually what I need. I have been testing it and
>> notice
>> >> the
>> >> > value of the field has to be always greater for a new document to get
>> >> > indexed. if you send the same version number it doesn't work.
>> >> >
>> >> > Is it possible somehow to overwrite documents with the same version?
>> >> >
>> >> > Thanks
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > View this message in context: http://lucene.472066.n3.
>> >> > nabble.com/version-Versioning-using-timespan-tp4338171p4338475.html
>> >> > Sent from the Solr - User mailing list archive at Nabble.com.
>> >> >
>> >>
>> >
>> >
>>
>
>
rote:
> >>
> >> > Thanks a lot Susheel.
> >> > I see this is actually what I need. I have been testing it and
> notice
> >> the
> >> > value of the field has to be always greater for a new document to get
> >> > indexed. if you send the same version number it doesn't work.
> >> >
> >> > Is it possible somehow to overwrite documents with the same version?
> >> >
> >> > Thanks
> >> >
> >> >
> >> >
> >> > --
> >> > View this message in context: http://lucene.472066.n3.
> >> > nabble.com/version-Versioning-using-timespan-tp4338171p4338475.html
> >> > Sent from the Solr - User mailing list archive at Nabble.com.
> >> >
> >>
> >
> >
>
e always greater for a new document to get
>> > indexed. if you send the same version number it doesn't work.
>> >
>> > Is it possible somehow to overwrite documents with the same version?
>> >
>> > Thanks
>> >
>> >
>> >
>> > --
>> > View this message in context: http://lucene.472066.n3.
>> > nabble.com/version-Versioning-using-timespan-tp4338171p4338475.html
>> > Sent from the Solr - User mailing list archive at Nabble.com.
>> >
>>
>
>
has to be always greater for a new document to get
> > indexed. if you send the same version number it doesn't work.
> >
> > Is it possible somehow to overwrite documents with the same version?
> >
> > Thanks
> >
> >
> >
> > --
> > View this
>
>
>
> --
> View this message in context: http://lucene.472066.n3.
> nabble.com/version-Versioning-using-timespan-tp4338171p4338475.html
> Sent from the Solr - User mailing list archive at Nabble.com.
>
?
Thanks
--
View this message in context:
http://lucene.472066.n3.nabble.com/version-Versioning-using-timespan-tp4338171p4338475.html
Sent from the Solr - User mailing list archive at Nabble.com.
"Document Centric Versioning Constraints" is what you are looking for if
you want this to handled in Solr
https://cwiki.apache.org/confluence/display/solr/Updating+Parts+of+Documents
--
Susheel
On Wed, May 31, 2017 at 6:46 AM, marotosg <marot...@gmail.com> wrote:
>
field where I send always the
timespam of last update to the entity.
Is this going to reject earlier versions if a newer is already indexed?
Thanks,
Sergio
--
View this message in context:
http://lucene.472066.n3.nabble.com/version-Versioning-using-timespan-tp4338171.html
Sent from the Solr
On 5/26/2016 2:37 AM, Nuhaa All Bakry wrote:
> Wondering if versioning is built-in in Solr? Say I have deployed a working
> SolrCloud (v1.0) and there are applications consuming the REST APIs. Is there
> a way to deploy the next v1.1 without removing v1.0? The reason I ask is
> bec
Hello,
Wondering if versioning is built-in in Solr? Say I have deployed a working
SolrCloud (v1.0) and there are applications consuming the REST APIs. Is there a
way to deploy the next v1.1 without removing v1.0? The reason I ask is because
we dont want the deployment of Solr to be tightly
On 3/2/2015 4:32 AM, marotosg wrote:
Is there any general approach to check if your indexed document matches the
database row?.
No, there's nothing out of the box that will do this. You'll need to
write such an application yourself. You might want to leverage the
/export handler in your
to be very
intensive.
I was more on the opinion of solr telling the record indexed and content
like number of nested docs of type A,B etc.,
Any suggestions would help.
Thanks
Regards
--
View this message in context:
http://lucene.472066.n3.nabble.com/Validate-data-Indexed-and-versioning
by the batch in question and compare to the SQL summary.
-Original Message-
From: marotosg [mailto:marot...@gmail.com]
Sent: Monday, March 02, 2015 6:32 AM
To: solr-user@lucene.apache.org
Subject: Validate data Indexed and versioning
Hi,
I am trying to define a way of validating if my index has
enough ?
--
View this message in context:
http://lucene.472066.n3.nabble.com/Document-versioning-support-tp4168417.html
Sent from the Solr - User mailing list archive at Nabble.com.
Depends on exactly what you mean by versioning. But if you mean that
every document in Solr gets a version-number which is increased every
time the document is updated, all you need to do is to add a _version_
field in you schema: http://wiki.apache.org/solr/SolrCloud#Required_Config
Believe
Created SOLR-3178 covering the versioning/optimistic-locking part. In
combination SOLR-3173 and SOLR-3178 should provide the features I am
missing, and that I believe lots of other SOLR users will be able to
benefit from. Please help shape by commenting on the Jira issues. Thanks.
Per
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 and
optimistic locking (versioning)?
Unique
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
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
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
On Fri, Feb 24, 2012 at 12:06 PM, Per Steffensen st...@designware.dk 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
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 currently
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
On Fri, Feb 24, 2012 at 6:55 AM, Em mailformailingli...@yahoo.de 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
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
Yonik Seeley skrev:
On Fri, Feb 24, 2012 at 6:55 AM, Em mailformailingli...@yahoo.de 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
On Fri, Feb 24, 2012 at 9:04 AM, Per Steffensen st...@designware.dk 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
Yonik Seeley skrev:
On Fri, Feb 24, 2012 at 9:04 AM, Per Steffensen st...@designware.dk 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
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 with
usable feature.
Our current distributed indexing (solr cloud) design explicitly took
optimistic concurrency into account, and it's been on my todo list.
It should actually be pretty easy - we have all the plumbing in place
now that we already use for distributed indexing.
For example, versioning
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
explicitly took
optimistic concurrency into account, and it's been on my todo list.
It should actually be pretty easy - we have all the plumbing in place
now that we already use for distributed indexing.
For example, versioning is already used to handle reorders of updates
when a leader forwards
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
id already exists. So it is not the whole solution.
Optimistic locking (versioning)
... is not provided by Solr out of the box. If you add a new document
with the same UniqueKey it replaces the old one.
You have to do the versioning on your own (and keep in mind concurrent
updates).
Kind
a unique key constraint, so that
you are not allowed to create a document with an id's when an document
with the same id already exists. So it is not the whole solution.
Optimistic locking (versioning)
... is not provided by Solr out of the box. If you add a new document
with the same
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
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
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 you
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 will be made
according
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
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.g. an id field). Of course
Hi Per,
Solr provides the so called UniqueKey-field.
Refer to the Wiki to learn more:
http://wiki.apache.org/solr/UniqueKey
Optimistic locking (versioning)
... is not provided by Solr out of the box. If you add a new document
with the same UniqueKey it replaces the old one.
You have to do
A customer has an interesting problem: some documents will have multiple
versions. In search results, only the most recent version of a given
document should be shown. The trick is that each user has access to a
different set of document versions, and each user should see only the
most recent
Hi Michael, I guess this could be solved using grouping as you said.
Documents inside a group can be sorted on a field (in your case, the version
field, see parameter group.sort), and you can show only the first one. It
will be more complex to show facets (post grouping faceting is work in
Thanks, Tomas. Yes we are planning to keep a current flag in the most
current document. But there are cases where, for a given user, the most
current document is not that one, because they only have access to some
older documents.
I took a look at http://wiki.apache.org/solr/FieldCollapsing
Hi Mike, how many docs and groups do you have in your index?
I think the group.sort option fits your requirements.
If I remember correctly group.ngroup=true adds something like 30% extra time
on top of the search request with grouping,
but that was on my local test dataset (~30M docs, ~8000
I think a 30% increase is acceptable. Yes, I think we'll try it.
Although our case is more like # groups ~ # documents / N, where N is a
smallish number (~1-5?). We are planning for a variety of different
index sizes, but aiming for a sweet spot around a few M docs.
-Mike
On 08/01/2011
: 1. Is this the plan moving forward (to aim for a new minor release
: approximately every couple of months)?
The goal is to release minor versions more frequently as features and
low priority bug fixes are available. If there is a high priority bug fix
available, and and no likelihood of a
be backwards compatible (so I could
upgrade from 3.x to 3.y where y x without having to update the
schema/config or rebuild the indexes)?
It might be worth sticking something up on the wiki which gives an overview
of the versioning policy just to clarify things. (I had a look and couldn't
find anything
versioning policy
: Also, are there any plans to split solr into a release/development mode?
:
: I'd really like to use solr in a commercial setting, but having nothing
but
: nightly builds available makes me uneasy.
I believe that as long as Solr is in the incubator, nightly builds are the
only
: http://svn.apache.org/viewvc/incubator/solr/trunk/CHANGES.txt
:
: But it is imperfect... Perhaps an entry should be added when updating
: the Lucene version too.
+1 ... definitely.
-Hoss
: Also, are there any plans to split solr into a release/development mode?
:
: I'd really like to use solr in a commercial setting, but having nothing but
: nightly builds available makes me uneasy.
I believe that as long as Solr is in the incubator, nightly builds are the
only releases we are
54 matches
Mail list logo
