[
https://issues.apache.org/jira/browse/SOLR-4085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13508703#comment-13508703
]
Mikhail Khludnev edited comment on SOLR-4085 at 12/3/12 5:46 PM:
-----------------------------------------------------------------
- I agree. For me EFF is a workaround until we have field updates, or
updateable DocValues, which is my dream btw.
- Then, issue which you mention is "delta reload". At contrast to the other
ones it's the simplest and even trivial task. It's a plain java coding
actually, there is no challenge in lucene internals here!
-- Straightforward -silly- approach is introducing "delta file" naming
convention. i.e. external_rating_2012112812.txt will be "patched" by delta file
external_rating_2012112812.delta etc.
-- But much more conscious approach is introduce ExternalDataAPI which will be
backed onto current "file" impl and then can have few more efficient impls,
supports delta updates. I think it can be the next step forward.
- if (fieldA > 0) { return fieldB / fieldA } else { return 0 } is an absolutely
hit. Here I can only suggest to introduce zeroProofDivision function. There is
no easy way to fix it in Lucene, because search request has no context there,
at contrast to solr where it can be handled at QParser. We can try to achieve
it by tricky query "warmer", which will dedupe queries before passing them into
Lucene search
- concurrent reloads are not a EFF's sin. Someone can easily shoot the leg is
start two dataimport processes in parallel, you know. Solr doesn't really
protects from 'lifecycle' errors, like accidentally enabled "autocommit"
- don't you think that Resolving the issue with such strict verdict can scare
away other committers. Can you ping someone as well you expressed you point of
view? I wanted to involve [~ysee...@gmail.com] or [~hossman_luc...@fucit.org],
but hesitated to disturb them.
was (Author: mkhludnev):
- I agree. For me EFF is a workaround until we have field updates, or
updateable DocValues, which is my dream btw.
- Then, issue which you mention is "delta reload". At contrast to the other
ones it's the simplest and even trivial task. It's a plain java coding
actually, there is no challenge in lucene internals here!
-- Straightforward -silly- approach is introducing "delta file" naming
convention. i.e. external_rating_2012112812.txt will be "patched" by delta file
external_rating_2012112812.delta etc.
-- But much more conscious approach is introduce ExternalDataAPI which will be
backed onto current "file" impl and then can have few more efficient impls,
supports delta updates. I think it can be the next step forward.
- if (fieldA > 0) { return fieldB / fieldA } else { return 0 } is an absolutely
hit. Here I can only suggest to introduce zeroProofDivision function. There is
no easy way to fix it in Lucene, because search request has no context there,
at contrast to solr where it can be handled at QParser. We can try to achieve
it by tricky query "warmer", which will dedupe queries before passing them into
Lucene search
- concurrent reloads are not a EFF's sin. Someone can easily shoot the leg is
start two dataimport processes in parallel, you know. Solr doesn't really
protects from 'lifecycle' errors, like accidentally enabled "autocommit"
- don't you think that Resolving the issue with such strick verdict can scare
away other committers. Can you ping someone as well you expressed you point of
view? I wanted to involve [~ysee...@gmail.com] or [~hossman_luc...@fucit.org],
but hesitated to disturb them.
> Commit-free ExternalFileField
> -----------------------------
>
> Key: SOLR-4085
> URL: https://issues.apache.org/jira/browse/SOLR-4085
> Project: Solr
> Issue Type: Improvement
> Components: Schema and Analysis
> Affects Versions: 4.1
> Reporter: Mikhail Khludnev
> Labels: externalfilefield
> Attachments: SOLR-4085.patch
>
>
> Let's reload ExternalFileFields without commit!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
