Great,
Thank you for confirming. This will help other people seeing similar
kinds of issues.
Regards,
Alex.
Solr Analyzers, Tokenizers, Filters, URPs and even a newsletter:
http://www.solr-start.com/
On 9 March 2015 at 05:02, Makailol Charls <4extrama...@gmail.com> wrote:
> Hi,
>
> As su
Hi,
As suggested, we could manage to activate the document expiration using TTL
by shifting the newly added URP setting in the starting of the
add-unknown-fields-to-the-schema URP. That populates the "expire_at_dt"
field and makes document to expire after defined TTL.
Many Thanks,
Makailol
On Fr
Hi,
As suggested, we could manage to activate the document expiration using TTL
by shifting the newly added URP setting in the starting of the
add-unknown-fields-to-the-schema URP. That populates the "expire_at_dt"
field and makes document to expire after defined TTL.
Many Thanks,
Makailol
On Fr
: There were no changes made in the solrconfig.xml file except added that
:
: block.
ok, first off: if you already *had* another updateRequestProcessorChain
that said 'default="true"' just adding a new one would be weird and would
likely give you errors. you have t oconsider the whole context
Yep,
Your default URP chain is probably not being triggered due to the
initParams. initParams are new in Solr 5, so this is still rough
around the edges advice.
But try giving your chain a name and adding explicit "update.chain"
value to the requestHandler section (not initParams) section.
Alter
Hi
Thanks for the reply.
I am just beginning with the solr, so not much familiar with the settings
of the solr. I have created solr "collection1" core with the following
command.
bin/solr create -c collection1
Then modified the managed-schema file to add required field definitions
There were n
Hi,
Thanks for the reply.
I tried adding following code block in in solrconfig.xml.
timestamp_dt
and added field definition in managed-schema
But then dont see this field is getting populated in document.
Thanks,
Makailol
On Thu, Feb 26, 2015 at 8:08 PM, Alexandre Rafalovitch
wrote:
: If your expire_at_dt field is not populated automatically, let's step
: back and recheck a sanity setting. You said it is a managed schema? Is
: it a schemaless as well? With an explicit processor chain? If that's
: the case, your default chain may not be running AT ALL.
yeah ... my only gu
If your expire_at_dt field is not populated automatically, let's step
back and recheck a sanity setting. You said it is a managed schema? Is
it a schemaless as well? With an explicit processor chain? If that's
the case, your default chain may not be running AT ALL.
So, recheck your solrconfig.
Hi Alex,
Thanks for the reply.
Yes, we have already tried to set the autoDeletePeriodSeconds period to
some low value like 5 seconds and tried checking the document expiration
after 30 seconds or minute or even after an hour. But result is same and
document does not get expired automatically.
Th
Hi
Thanks for your quick reply.
" since your time_to_live_s and expire_at_dt fields are both
stored, can you confirm that a expire_at_dt field is getting popularted by
the update processor by doing as simple query for your doc (ie
q=id:10seconds) "
No, expire_at_dt field does not get populated w
: Following query posts a document and sets "expire_at_dt" explicitly. That
: is working perfectly ok and ducument expires at defined time.
so the delete trigge logic is working correctly...
: But when trying to post with TTL (following query), document does not
: expire after given time.
...wh
Reading https://lucidworks.com/blog/document-expiration/
It seems that your Delete check interval granularity is 30 seconds,
but your TTL is 10 seconds. Have you tried setting
autoDeletePeriodSeconds to something like 2 seconds and seeing if the
problem goes away due to more frequent checking of i
13 matches
Mail list logo
