> > >> > 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 Kumar
> wrote:
> > >> >
> > >> >> Which version of solr are you using? I tested in 6.0 and if I
> supply
> > >> same
> > >> >> version, it overwrite/update the document exactly as per the wiki
> > >> >> documentation.
> > >> >>
> > >> >> Thanks,
> > >> >> Susheel
> > >> >>
> > >> >> On Thu, Jun 1, 2017 at 7:57 AM, marotosg
> 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.
> > >> >> >
> > >> >>
> > >> >
> > >> >
> > >>
> > >
> > >
> >
>
you have any tip on how to get same versions not getting rejected.
> >> >
> >> > Thanks a lot.
> >> >
> >> >
> >> > On 1 June 2017 at 19:04, Susheel Kumar wrote:
> >> >
> >> >> Which version of solr are you using? I tested in 6.0 and if I supply
> >> same
> >> >> version, it overwrite/update the document exactly as per the wiki
> >> >> documentation.
> >> >>
> >> >> Thanks,
> >> >> Susheel
> >> >>
> >> >> On Thu, Jun 1, 2017 at 7:57 AM, marotosg 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.
> >> >> >
> >> >>
> >> >
> >> >
> >>
> >
> >
>
>> > On 1 June 2017 at 19:04, Susheel Kumar wrote:
>> >
>> >> Which version of solr are you using? I tested in 6.0 and if I supply
>> same
>> >> version, it overwrite/update the document exactly as per the wiki
>> >> documentation.
>> >>
>&g
pdate the document exactly as per the wiki
> >> documentation.
> >>
> >> Thanks,
> >> Susheel
> >>
> >> On Thu, Jun 1, 2017 at 7:57 AM, marotosg wrote:
> >>
> >> > Thanks a lot Susheel.
> >> > I see this is a
2017 at 7:57 AM, marotosg 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 s
gt; 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.
&g
; --
> 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.
>
rsion?
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 wrote:
> Hi all.
>
> I need to impl
sion_ 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
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 appl
ope the
facet queries 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
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
can do the same ? Or my solution
is good 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_Conf
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
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
urrent 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, versio
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
ommonly 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,
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
ot; 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, becaus
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 do
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
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
p://wiki.apache.org/solr/UniqueKey
>>
> Belive the uniqueKey does not enforce 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.
>>
hen 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 UniqueKey it replaces the old one.
You have to do the versioning on your own (and keep i
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
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 to
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.
Y
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
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 11:
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 groups
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/FieldCollapsin
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
progress
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 v
: 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
ys 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
ucene 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 ar
: 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 al
: 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
On 6/8/06, Mike Klaas <[EMAIL PROTECTED]> wrote:
Even something as simple as 'tagging' a nightly build that contains
major changes (with a brief changelog) would be helpful. It would
also be valuable from a project history perspective.
We try to record all non-trivial changes that can have an
On 6/8/06, Yonik Seeley <[EMAIL PROTECTED]> wrote:
> I'd really like to use solr in a commercial setting, but having nothing but
> nightly builds available makes me uneasy.
Anything you develop would need to be QA'd for a commercial setting
anyway. Perhaps you could pick the latest nightly bui
On 6/8/06, Mike Klaas <[EMAIL PROTECTED]> wrote:
I was curious as to policy regarding being current with the lucene
codebase. Does solr use the lastest stable release? bleeding edge
(trunk?) Occasional manual svn import?
An occasional SVN import based on need (same as hadoop/nutch as far as
Hello,
I was curious as to policy regarding being current with the lucene
codebase. Does solr use the lastest stable release? bleeding edge
(trunk?) Occasional manual svn import?
Also, are there any plans to split solr into a release/development mode?
I'd really like to use solr in a commerc
58 matches
Mail list logo
