Thank you for theses informations, I'll keep that in mind.
But i'm sorry, i don't get it about the process to do it ???
Em wrote
>
> Well, you could create a keyword-file out of your database and join it
> with your self-maintained keywordslist.
>
By that you mean :
- 'self-maintained keyw
Btw.:
Solr has no downtime while reloading the core.
It loads the new core and while loading the new one it still serves
requests with the old one.
When the new one is ready (and warmed up) it finally replaces the old core.
Best,
Em
Am 22.02.2012 17:56, schrieb Xavier:
> I'm not sure to understan
If you use the suggested solution, it will detect the words at indexing
time.
However, Solr's FilterFactory's lifecycle keeps no track on whether a
file for synonyms, keywords etc. has been changed since Solr's last startup.
Therefore a change within these files is not visible until you reload
your
I'm not sure to understand your solution ?
When (and how) will be the 'word' detection in the fulltext ? before (by my
own) or during (with) solr indexation ?
--
View this message in context:
http://lucene.472066.n3.nabble.com/How-to-merge-an-autofacet-with-a-predefined-facet-tp3763988p3767059.h
: But i don't know if it's possible to merge this "autocreated" facet with a
: facet already predefined ? i tried to used (adding this to my
: code in my previous post) :
: **
copyField applies to the raw input of those fields -- so the special logic
you have in the analyzer for your text_tag_
Well, you could create a keyword-file out of your database and join it
with your self-maintained keywordslist.
Doing so, keep in mind that you have to reload your SolrCore in order to
make the changes visible to the indexing-process (and keep in mind that
you have to reindex those documents that ma
In a way I agree that it would be easier to do that but i really wants to
avoid this solution because it prefer to work "harder" on preparing my index
than adding field requests on my front query :)
So the only solution i see right now is to do that on my own in order to
have my database fully pre
Wouldn't it be easier to store both types in different fields?
At query-time you are able to do a facet on both and can combine the
results client-side to present them within the GUI.
Kind regards,
Em
Am 21.02.2012 17:52, schrieb Xavier:
> Sure, the difference between my 2 facets are :
>
> - 'pr
Sure, the difference between my 2 facets are :
- 'predefined_facets' contains values already filled in my database like :
'web langage', 'cooking', 'fishing'
- 'text_tag_facets' will contain the same possible value but determined
automatically from a given wordslist by searching in the docum
Hi Xavier,
> It's maybe because (As I understood) the real (stored) value of this
dynamic
> facet is still the initial fulltext ?? (or maybe i'm wrong ...)
Exactly.
CopyField does not copy the analyzed result of a field into another one.
Instead, the original content given to that field (the unan
10 matches
Mail list logo