check out the videos on this website TROO.TUBE don't be such a
sheep/zombie/loser/NPC. Much love!
https://troo.tube/videos/watch/aaa64864-52ee-4201-922f-41300032f219
On Wed, May 13, 2020 at 7:24 AM Bernd Fehling
wrote:
>
> Thanks Eric for your answer.
>
> I was thinking to complex and seeing prob
Thanks Eric for your answer.
I was thinking to complex and seeing problems which are not there.
I have your second scenario. The first huge collection still remains
and will grow further while the second will start with same schema but
content from a new source. Sure I could also load the content
So a doc in your new collection is expected to supersede a doc
with the same ID in the old one, right?
What I’d do is delete the IDs from my old collection as they were added to
the new one, there’s not much use in keeping both if you always want
the new one.
Let’s assume you do this, the next i
Hi Daniel,
Thanks so much for your inputs. I tried this with SOLR 6.1.0 fresh data and
if i use id field as long, the target site is not able to replay the
transaction when we use delete by id. I opened a ticket in JIRA -
https://issues.apache.org/jira/browse/SOLR-9394. Below is the exception on
t
This vaguely rings a bell, though from a long time ago. We had our id
field using the "lowercase" type in Solr, and that broke/changed somewhere
in the 4.x series (we are on 4.8.1 now and it doesn't work there), so we
have to revert to a simple "string" type instead. I know you have a very
differ
See http://wiki.apache.org/solr/DataImportHandler#FileListEntityProcessor
"The implicit fields generated by the FileListEntityProcessor are
fileDir, file, fileAbsolutePath, fileSize, fileLastModified and these
are available for use within the entity"
On Tue, Jul 2, 2013 at 2:47 PM, archit2112 wr
Yes. The absolute path is unique. How do i implement it? can you please
explain?
--
View this message in context:
http://lucene.472066.n3.nabble.com/Unique-key-error-while-indexing-pdf-files-tp4074314p4074638.html
Sent from the Solr - User mailing list archive at Nabble.com.
Yes. The absolute path is unique.
--
View this message in context:
http://lucene.472066.n3.nabble.com/Unique-key-error-while-indexing-pdf-files-tp4074314p4074620.html
Sent from the Solr - User mailing list archive at Nabble.com.
We can't tell you what the id of your own document should be. Isn't
there anything which is unique about your pdf files? How about the
file name or the absolute path?
On Tue, Jul 2, 2013 at 11:33 AM, archit2112 wrote:
> Okay. Can you please suggest a way (with an example) of assigning this unique
Okay. Can you please suggest a way (with an example) of assigning this unique
key to a pdf file. Say, a unique number to each pdf file. How do i achieve
this?
--
View this message in context:
http://lucene.472066.n3.nabble.com/Unique-key-error-while-indexing-pdf-files-tp4074314p4074592.html
Sen
Can you please suggest a way (with example) of assigning this unique key to a
pdf file?
--
View this message in context:
http://lucene.472066.n3.nabble.com/Unique-key-error-while-indexing-pdf-files-tp4074314p4074588.html
Sent from the Solr - User mailing list archive at Nabble.com.
: Monday, July 01, 2013 8:30 AM
To: solr-user@lucene.apache.org
Subject: Re: Unique key error while indexing pdf files
Im new to solr. Im just trying to understand and explore various features
offered by solr and their implementations. I would be very grateful if you
could solve my problem with a
Im new to solr. Im just trying to understand and explore various features
offered by solr and their implementations. I would be very grateful if you
could solve my problem with any example of your choice. I just want to learn
how i can index pdf documents using data import handler.
--
View this
It all depends on your data model - tell us more about your data model.
For example, how will users or applications query these documents and what
will they expect to be able to do with the ID/key for the documents?
How are you expecting to identify documents in your data model?
-- Jack Krupa
No, a unique key needs to be indexed. You can delete documents by query (to
avoid duplication), but you can't query on any field that is not indexed,
so I guess you'll need it.
On Tue, Jul 10, 2012 at 12:23 PM, Sachin Aggarwal <
different.sac...@gmail.com> wrote:
> today i experimented some param
There are some specific use cases where you can skip having a unique key.
See http://wiki.apache.org/solr/UniqueKey
However, I would test how much space you save by not having one.
On Tue, Jul 10, 2012 at 6:27 AM, Sachin Aggarwal wrote:
> in my use case i m not deleting any doc from solr i m usi
in my use case i m not deleting any doc from solr i m using batch build on
data and use solr as filters on data data is very large raw rows are in
billions and filtered or searched query are in millions...is there any way
to leave unique key from indexing
On Tue, Jul 10, 2012 at 3:42 PM, Tomás Fer
In order to support updates (which are treated as deleted + add), the
unique key needs to be indexed.
Tomás
On Tue, Jul 10, 2012 at 6:08 AM, Sachin Aggarwal wrote:
> is it possible not to index and but store the unique keyit will make
> index size small. i need the unique key to b stored so
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 Steffens
Created SOLR-3173 on the part about making insert fail if document (with
same uniqueKey) already exists. SOLR-3173 also includes to make "update"
not insert document if not already exists - just for consistency with
normal RDBMS behaviour. So basically the feature allowes you to turn on
this be
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
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.
However this is not the whole story, since this "constraint" only works
per index/SolrCore/Sha
Em skrev:
Hi Per,
Solr provides the so called "UniqueKey"-field.
Refer to the Wiki to learn more:
http://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 sa
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
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.
You have to do the
: Subject: Re: Unique Key error on trunk
:
:
: You can replicate it with the example app by replacing the id definition in
schema.xml with
:
: >
thanks for reporting this Viswa, I've filed a bug to track it...
https://issues.apache.org/jira/browse/SOLR-2796
-Hoss
You can replicate it with the example app by replacing the id definition in
schema.xml with
>
Removing the id fields in the one of the example doc.xml and posting it to solr.
Thanks
Viswa
On Sep 26, 2011, at 12:15 AM, Viswa S wrote:
> Hello,
>
> We use solr.UUIDField to generate unique
On Wed, 6 Aug 2008 12:25:34 +1000
Norberto Meijome <[EMAIL PROTECTED]> wrote:
> On Tue, 5 Aug 2008 14:41:08 -0300
> "Scott Swan" <[EMAIL PROTECTED]> wrote:
>
> > I currently have multiple documents that i would like to index but i would
> > like to combine two fields to produce the unique key.
>
On Tue, 5 Aug 2008 14:41:08 -0300
"Scott Swan" <[EMAIL PROTECTED]> wrote:
> I currently have multiple documents that i would like to index but i would
> like to combine two fields to produce the unique key.
>
> the documents either have 1 or the other fields so by combining the two
> fields i w
48 matches
Mail list logo
