public Integer run() {
try {
return cache.get(getCacheKey(), callable);
} catch (ExecutionException e) {
throw new ScriptException(e.getMessage(), e);
}
}
and the callable is:
new Callable() {
@Override
public Integer call() throws Exception {
return getCalculatedResult();
}
};
Could you please help me to create a proper cache key? I want to keep
unique results for each document/index. As I understand, cache is shared
between multiple indices, so I need to put it in the cache key.
Questions:
What should I use to identify the document? Can I use
indexLookup().getDocId()? Or I should use docFieldLongs("id").getValue() (I
have this field in documents)? Can I access "_id" property?
indexlookup().getDocId() will not work since these ids change when there is
a merge. Using a document property is a better idea if the output of your
computation solely depends on this value. The default configuration does
not let you have access to _id, but you have _uid however. Beware that you
might want to also take the index name into account if your cluster is
serving several indices... But before adding caching, I think it would help
to figure out if it would be possible to not need caching, eg. by modeling
data differently?
On Mon, Mar 16, 2015 at 5:32 PM, Sergey Novikov snov@snov.me wrote:
public Integer run() {
try {
return cache.get(getCacheKey(), callable);
} catch (ExecutionException e) {
throw new ScriptException(e.getMessage(), e);
}
}
and the callable is:
new Callable() {
@Override
public Integer call() throws Exception {
return getCalculatedResult();
}
};
Could you please help me to create a proper cache key? I want to keep
unique results for each document/index. As I understand, cache is shared
between multiple indices, so I need to put it in the cache key.
Questions:
What should I use to identify the document? Can I use
indexLookup().getDocId()? Or I should use docFieldLongs("id").getValue()
(I have this field in documents)? Can I access "_id" property?
The output of computation depends on document data, and script parameters.
It works already ok, but with caching it seems to be several times faster.
Do you know if it's possible to get the index name from within the script?
I understand I can pass it with the script parameters, but is there a
better solution? Maybe it's already available to the script?
On Monday, March 16, 2015 at 7:20:49 PM UTC+1, Adrien Grand wrote:
indexlookup().getDocId() will not work since these ids change when there
is a merge. Using a document property is a better idea if the output of
your computation solely depends on this value. The default configuration
does not let you have access to _id, but you have _uid however. Beware that
you might want to also take the index name into account if your cluster is
serving several indices... But before adding caching, I think it would help
to figure out if it would be possible to not need caching, eg. by modeling
data differently?
On Mon, Mar 16, 2015 at 5:32 PM, Sergey Novikov <sn...@snov.me
<javascript:>> wrote:
public Integer run() {
try {
return cache.get(getCacheKey(), callable);
} catch (ExecutionException e) {
throw new ScriptException(e.getMessage(), e);
}
}
and the callable is:
new Callable() {
@Override
public Integer call() throws Exception {
return getCalculatedResult();
}
};
Could you please help me to create a proper cache key? I want to keep
unique results for each document/index. As I understand, cache is shared
between multiple indices, so I need to put it in the cache key.
Questions:
What should I use to identify the document? Can I use
indexLookup().getDocId()? Or I should use docFieldLongs("id").getValue()
(I have this field in documents)? Can I access "_id" property?
I haven't tried, but getting the value of the _index field should work.
On Mon, Mar 16, 2015 at 12:42 PM, Sergey Novikov snov@snov.me wrote:
Hi Adrien,
Thank you for the answer.
The output of computation depends on document data, and script parameters.
It works already ok, but with caching it seems to be several times faster.
Do you know if it's possible to get the index name from within the script?
I understand I can pass it with the script parameters, but is there a
better solution? Maybe it's already available to the script?
On Monday, March 16, 2015 at 7:20:49 PM UTC+1, Adrien Grand wrote:
indexlookup().getDocId() will not work since these ids change when there
is a merge. Using a document property is a better idea if the output of
your computation solely depends on this value. The default configuration
does not let you have access to _id, but you have _uid however. Beware that
you might want to also take the index name into account if your cluster is
serving several indices... But before adding caching, I think it would help
to figure out if it would be possible to not need caching, eg. by modeling
data differently?
On Mon, Mar 16, 2015 at 5:32 PM, Sergey Novikov sn...@snov.me wrote:
public Integer run() {
try {
return cache.get(getCacheKey(), callable);
} catch (ExecutionException e) {
throw new ScriptException(e.getMessage(), e);
}
}
and the callable is:
new Callable() {
@Override
public Integer call() throws Exception {
return getCalculatedResult();
}
};
Could you please help me to create a proper cache key? I want to keep
unique results for each document/index. As I understand, cache is shared
between multiple indices, so I need to put it in the cache key.
Questions:
What should I use to identify the document? Can I use
indexLookup().getDocId()? Or I should use docFieldLongs("id").getValue()
(I have this field in documents)? Can I access "_id" property?
it works fine: docFieldStrings("_index") and docFieldStrings("_uid")
Thanks for your help.
On Monday, March 16, 2015 at 9:41:46 PM UTC+1, Adrien Grand wrote:
I haven't tried, but getting the value of the _index field should work.
On Mon, Mar 16, 2015 at 12:42 PM, Sergey Novikov <sn...@snov.me
<javascript:>> wrote:
Hi Adrien,
Thank you for the answer.
The output of computation depends on document data, and script
parameters. It works already ok, but with caching it seems to be several
times faster.
Do you know if it's possible to get the index name from within the
script? I understand I can pass it with the script parameters, but is there
a better solution? Maybe it's already available to the script?
On Monday, March 16, 2015 at 7:20:49 PM UTC+1, Adrien Grand wrote:
indexlookup().getDocId() will not work since these ids change when there
is a merge. Using a document property is a better idea if the output of
your computation solely depends on this value. The default configuration
does not let you have access to _id, but you have _uid however. Beware that
you might want to also take the index name into account if your cluster is
serving several indices... But before adding caching, I think it would help
to figure out if it would be possible to not need caching, eg. by modeling
data differently?
On Mon, Mar 16, 2015 at 5:32 PM, Sergey Novikov sn...@snov.me wrote:
public Integer run() {
try {
return cache.get(getCacheKey(), callable);
} catch (ExecutionException e) {
throw new ScriptException(e.getMessage(), e);
}
}
and the callable is:
new Callable() {
@Override
public Integer call() throws Exception {
return getCalculatedResult();
}
};
Could you please help me to create a proper cache key? I want to keep
unique results for each document/index. As I understand, cache is shared
between multiple indices, so I need to put it in the cache key.
Questions:
What should I use to identify the document? Can I use
indexLookup().getDocId()? Or I should use
docFieldLongs("id").getValue() (I have this field in documents)? Can I
access "_id" property?
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.