Java-api: SearchHitField usage

Elastic Stack Elasticsearch
1

Hello,

when I get back a SearchHit hit, I can get back the fields with
hit.getFields();

This leads to a Map<String, SearchHitField> where String is the name
of the field and SearchHitField actually is an Interface just having:

String name();
Object value();
List values();

(plus getters with get..);

Actually is there a special reason there is no Map<String, String>
hit.getSimpleFields(); or sth. like that in it as I don*t see the
reason to get back a map of Objects that contains the key as String
name plus and Object Value that is the content of the field (the idea
with List seems bit strange to me - either I get back an
Object thst is instance of List or not - but a List is actually an
Object when it exists as List itself is just a specialized interface
derived from Collection - so, this is not good in terms of OO imho);

Best

2

A field, when stored / executed as a script, can be retrieved, and when fetched, it can be of different types (numeric, string, and so on). Thats the reason why the type if Object, if you want the String representation, you can call toString on it.

The reason why it has both value() and values() is because a field can have several values for it indexed (for example, an array of values). So, when stored, you can get the list of values associated with it (in which case, the value method will just return the first one). The reason its a List is because it maintains the order of the values indexed.
On Friday, March 11, 2011 at 5:09 PM, K.B. wrote:
Hello,

when I get back a SearchHit hit, I can get back the fields with
hit.getFields();

This leads to a Map<String, SearchHitField> where String is the name
of the field and SearchHitField actually is an Interface just having:

String name();
Object value();
List values();

(plus getters with get..);

Actually is there a special reason there is no Map<String, String>
hit.getSimpleFields(); or sth. like that in it as I don*t see the
reason to get back a map of Objects that contains the key as String
name plus and Object Value that is the content of the field (the idea
with List seems bit strange to me - either I get back an
Object thst is instance of List or not - but a List is actually an
Object when it exists as List itself is just a specialized interface
derived from Collection - so, this is not good in terms of OO imho);

Best

3

Hey Shay,

I understand but as a Java programmer, I still feel uncomfortable:
getting back a List is ok as well as an Object, but those together is
not good; Reason is simply any List is also an object, so to be it
correctly it's just:

String name;
Object value;

and in case you get back many objects the value is an Object of
interface type List, meaning a single List object :slight_smile:

Also in runtime its not sure if you will get back a single object or a
list (remember, we have no schema usually), so you need to care anyway
with the danger of getting an Object holding other object's in it;

Following that, the logical consequence for regular SearchHit's is to
strip the class as same behaviour can be achived by giving back a
Map<String, Object>;

Best

On 12 Mrz., 08:13, Shay Banon shay.ba...@elasticsearch.com wrote:

A field, when stored / executed as a script, can be retrieved, and when fetched, it can be of different types (numeric, string, and so on). Thats the reason why the type if Object, if you want the String representation, you can call toString on it.

The reason why it has both value() and values() is because a field can have several values for it indexed (for example, an array of values). So, when stored, you can get the list of values associated with it (in which case, the value method will just return the first one). The reason its a List is because it maintains the order of the values indexed.On Friday, March 11, 2011 at 5:09 PM, K.B. wrote:

Hello,

when I get back a SearchHit hit, I can get back the fields with
hit.getFields();

This leads to a Map<String, SearchHitField> where String is the name
of the field and SearchHitField actually is an Interface just having:

String name();
Object value();
List values();

(plus getters with get..);

Actually is there a special reason there is no Map<String, String>
hit.getSimpleFields(); or sth. like that in it as I don*t see the
reason to get back a map of Objects that contains the key as String
name plus and Object Value that is the content of the field (the idea
with List seems bit strange to me - either I get back an
Object thst is instance of List or not - but a List is actually an
Object when it exists as List itself is just a specialized interface
derived from Collection - so, this is not good in terms of OO imho);

Best

4

You can treat the value method as a helper to get the first object in the list if the list is not empty. Otherwise, you can just use the values method that returns a List of objects if thats how you like it.
On Saturday, March 12, 2011 at 7:09 PM, K.B. wrote:

Hey Shay,

I understand but as a Java programmer, I still feel uncomfortable:
getting back a List is ok as well as an Object, but those together is
not good; Reason is simply any List is also an object, so to be it
correctly it's just:

String name;
Object value;

and in case you get back many objects the value is an Object of
interface type List, meaning a single List object :slight_smile:

Also in runtime its not sure if you will get back a single object or a
list (remember, we have no schema usually), so you need to care anyway
with the danger of getting an Object holding other object's in it;

Following that, the logical consequence for regular SearchHit's is to
strip the class as same behaviour can be achived by giving back a
Map<String, Object>;

Best

On 12 Mrz., 08:13, Shay Banon shay.ba...@elasticsearch.com wrote:

A field, when stored / executed as a script, can be retrieved, and when fetched, it can be of different types (numeric, string, and so on). Thats the reason why the type if Object, if you want the String representation, you can call toString on it.

The reason why it has both value() and values() is because a field can have several values for it indexed (for example, an array of values). So, when stored, you can get the list of values associated with it (in which case, the value method will just return the first one). The reason its a List is because it maintains the order of the values indexed.On Friday, March 11, 2011 at 5:09 PM, K.B. wrote:

Hello,

when I get back a SearchHit hit, I can get back the fields with
hit.getFields();

This leads to a Map<String, SearchHitField> where String is the name
of the field and SearchHitField actually is an Interface just having:

String name();
Object value();
List values();

(plus getters with get..);

Actually is there a special reason there is no Map<String, String>
hit.getSimpleFields(); or sth. like that in it as I don*t see the
reason to get back a map of Objects that contains the key as String
name plus and Object Value that is the content of the field (the idea
with List seems bit strange to me - either I get back an
Object thst is instance of List or not - but a List is actually an
Object when it exists as List itself is just a specialized interface
derived from Collection - so, this is not good in terms of OO imho);

Best

5

Yeah I know and it's not a problem for me, just an violation of OO-
principles :slight_smile:

Btw: I'm really suprised about the performance of ES - especially the
caching done to the filtered content really shines.

On 12 Mrz., 18:38, Shay Banon shay.ba...@elasticsearch.com wrote:

You can treat the value method as a helper to get the first object in the list if the list is not empty. Otherwise, you can just use the values method that returns a List of objects if thats how you like it.

On Saturday, March 12, 2011 at 7:09 PM, K.B. wrote:

Hey Shay,

I understand but as a Java programmer, I still feel uncomfortable:
getting back a List is ok as well as an Object, but those together is
not good; Reason is simply any List is also an object, so to be it
correctly it's just:

String name;
Object value;

and in case you get back many objects the value is an Object of
interface type List, meaning a single List object :slight_smile:

Also in runtime its not sure if you will get back a single object or a
list (remember, we have no schema usually), so you need to care anyway
with the danger of getting an Object holding other object's in it;

Following that, the logical consequence for regular SearchHit's is to
strip the class as same behaviour can be achived by giving back a
Map<String, Object>;

Best

On 12 Mrz., 08:13, Shay Banon shay.ba...@elasticsearch.com wrote:

A field, when stored / executed as a script, can be retrieved, and when fetched, it can be of different types (numeric, string, and so on). Thats the reason why the type if Object, if you want the String representation, you can call toString on it.

The reason why it has both value() and values() is because a field can have several values for it indexed (for example, an array of values). So, when stored, you can get the list of values associated with it (in which case, the value method will just return the first one). The reason its a List is because it maintains the order of the values indexed.On Friday, March 11, 2011 at 5:09 PM, K.B. wrote:

Hello,

when I get back a SearchHit hit, I can get back the fields with
hit.getFields();

This leads to a Map<String, SearchHitField> where String is the name
of the field and SearchHitField actually is an Interface just having:

String name();
Object value();
List values();

(plus getters with get..);

Actually is there a special reason there is no Map<String, String>
hit.getSimpleFields(); or sth. like that in it as I don*t see the
reason to get back a map of Objects that contains the key as String
name plus and Object Value that is the content of the field (the idea
with List seems bit strange to me - either I get back an
Object thst is instance of List or not - but a List is actually an
Object when it exists as List itself is just a specialized interface
derived from Collection - so, this is not good in terms of OO imho);

Best

6

So, I keep missing the violation of OO principles :). What would you suggest be the SearchHitField API? I did not fully understand.
On Saturday, March 12, 2011 at 8:56 PM, K.B. wrote:

Yeah I know and it's not a problem for me, just an violation of OO-
principles :slight_smile:

Btw: I'm really suprised about the performance of ES - especially the
caching done to the filtered content really shines.

On 12 Mrz., 18:38, Shay Banon shay.ba...@elasticsearch.com wrote:

You can treat the value method as a helper to get the first object in the list if the list is not empty. Otherwise, you can just use the values method that returns a List of objects if thats how you like it.

On Saturday, March 12, 2011 at 7:09 PM, K.B. wrote:

Hey Shay,

I understand but as a Java programmer, I still feel uncomfortable:
getting back a List is ok as well as an Object, but those together is
not good; Reason is simply any List is also an object, so to be it
correctly it's just:

String name;
Object value;

and in case you get back many objects the value is an Object of
interface type List, meaning a single List object :slight_smile:

Also in runtime its not sure if you will get back a single object or a
list (remember, we have no schema usually), so you need to care anyway
with the danger of getting an Object holding other object's in it;

Following that, the logical consequence for regular SearchHit's is to
strip the class as same behaviour can be achived by giving back a
Map<String, Object>;

Best

On 12 Mrz., 08:13, Shay Banon shay.ba...@elasticsearch.com wrote:

A field, when stored / executed as a script, can be retrieved, and when fetched, it can be of different types (numeric, string, and so on). Thats the reason why the type if Object, if you want the String representation, you can call toString on it.

The reason why it has both value() and values() is because a field can have several values for it indexed (for example, an array of values). So, when stored, you can get the list of values associated with it (in which case, the value method will just return the first one). The reason its a List is because it maintains the order of the values indexed.On Friday, March 11, 2011 at 5:09 PM, K.B. wrote:

Hello,

when I get back a SearchHit hit, I can get back the fields with
hit.getFields();

This leads to a Map<String, SearchHitField> where String is the name
of the field and SearchHitField actually is an Interface just having:

String name();
Object value();
List values();

(plus getters with get..);

Actually is there a special reason there is no Map<String, String>
hit.getSimpleFields(); or sth. like that in it as I don*t see the
reason to get back a map of Objects that contains the key as String
name plus and Object Value that is the content of the field (the idea
with List seems bit strange to me - either I get back an
Object thst is instance of List or not - but a List is actually an
Object when it exists as List itself is just a specialized interface
derived from Collection - so, this is not good in terms of OO imho);

Best

7

I would go the way SOLR went: just drop it - and so just return the
pure content object - be it a Long, a String or a List etc. ->
so field("name") would give back an object that the field-content is,
instead of Map<String, SearchHitField> getFields() it would be
Map<String, Object> getFields();

But as its used by many people it has to be deprecated first.... - or
let it just like it is and keep this in mind by future refining :wink:

BTW: why are nearly all getters existing duplicated? nearly all simple-
returning-functions exist as e.g.: getObject() and object();?
(also see SearchHitField interface for an example);

On 12 Mrz., 19:57, Shay Banon shay.ba...@elasticsearch.com wrote:

So, I keep missing the violation of OO principles :). What would you suggest be the SearchHitField API? I did not fully understand.

On Saturday, March 12, 2011 at 8:56 PM, K.B. wrote:

Yeah I know and it's not a problem for me, just an violation of OO-
principles :slight_smile:

Btw: I'm really suprised about the performance of ES - especially the
caching done to the filtered content really shines.

On 12 Mrz., 18:38, Shay Banon shay.ba...@elasticsearch.com wrote:

You can treat the value method as a helper to get the first object in the list if the list is not empty. Otherwise, you can just use the values method that returns a List of objects if thats how you like it.

On Saturday, March 12, 2011 at 7:09 PM, K.B. wrote:

Hey Shay,

I understand but as a Java programmer, I still feel uncomfortable:
getting back a List is ok as well as an Object, but those together is
not good; Reason is simply any List is also an object, so to be it
correctly it's just:

String name;
Object value;

and in case you get back many objects the value is an Object of
interface type List, meaning a single List object :slight_smile:

Also in runtime its not sure if you will get back a single object or a
list (remember, we have no schema usually), so you need to care anyway
with the danger of getting an Object holding other object's in it;

Following that, the logical consequence for regular SearchHit's is to
strip the class as same behaviour can be achived by giving back a
Map<String, Object>;

Best

On 12 Mrz., 08:13, Shay Banon shay.ba...@elasticsearch.com wrote:

A field, when stored / executed as a script, can be retrieved, and when fetched, it can be of different types (numeric, string, and so on). Thats the reason why the type if Object, if you want the String representation, you can call toString on it.

The reason why it has both value() and values() is because a field can have several values for it indexed (for example, an array of values). So, when stored, you can get the list of values associated with it (in which case, the value method will just return the first one). The reason its a List is because it maintains the order of the values indexed.On Friday, March 11, 2011 at 5:09 PM, K.B. wrote:

Hello,

when I get back a SearchHit hit, I can get back the fields with
hit.getFields();

This leads to a Map<String, SearchHitField> where String is the name
of the field and SearchHitField actually is an Interface just having:

String name();
Object value();
List values();

(plus getters with get..);

Actually is there a special reason there is no Map<String, String>
hit.getSimpleFields(); or sth. like that in it as I don*t see the
reason to get back a map of Objects that contains the key as String
name plus and Object Value that is the content of the field (the idea
with List seems bit strange to me - either I get back an
Object thst is instance of List or not - but a List is actually an
Object when it exists as List itself is just a specialized interface
derived from Collection - so, this is not good in terms of OO imho);

Best

8

Ok, now I understand, and don't agree. There are two separate notions here, a field can have multiple values, and it can be of different types. Those are two different things.
On Saturday, March 12, 2011 at 9:08 PM, K.B. wrote:

I would go the way SOLR went: just drop it - and so just return the
pure content object - be it a Long, a String or a List etc. ->
so field("name") would give back an object that the field-content is,
instead of Map<String, SearchHitField> getFields() it would be
Map<String, Object> getFields();

But as its used by many people it has to be deprecated first.... - or
let it just like it is and keep this in mind by future refining :wink:

BTW: why are nearly all getters existing duplicated? nearly all simple-
returning-functions exist as e.g.: getObject() and object();?
(also see SearchHitField interface for an example);

On 12 Mrz., 19:57, Shay Banon shay.ba...@elasticsearch.com wrote:

So, I keep missing the violation of OO principles :). What would you suggest be the SearchHitField API? I did not fully understand.

On Saturday, March 12, 2011 at 8:56 PM, K.B. wrote:

Yeah I know and it's not a problem for me, just an violation of OO-
principles :slight_smile:

Btw: I'm really suprised about the performance of ES - especially the
caching done to the filtered content really shines.

On 12 Mrz., 18:38, Shay Banon shay.ba...@elasticsearch.com wrote:

You can treat the value method as a helper to get the first object in the list if the list is not empty. Otherwise, you can just use the values method that returns a List of objects if thats how you like it.

On Saturday, March 12, 2011 at 7:09 PM, K.B. wrote:

Hey Shay,

I understand but as a Java programmer, I still feel uncomfortable:
getting back a List is ok as well as an Object, but those together is
not good; Reason is simply any List is also an object, so to be it
correctly it's just:

String name;
Object value;

and in case you get back many objects the value is an Object of
interface type List, meaning a single List object :slight_smile:

Also in runtime its not sure if you will get back a single object or a
list (remember, we have no schema usually), so you need to care anyway
with the danger of getting an Object holding other object's in it;

Following that, the logical consequence for regular SearchHit's is to
strip the class as same behaviour can be achived by giving back a
Map<String, Object>;

Best

On 12 Mrz., 08:13, Shay Banon shay.ba...@elasticsearch.com wrote:

A field, when stored / executed as a script, can be retrieved, and when fetched, it can be of different types (numeric, string, and so on). Thats the reason why the type if Object, if you want the String representation, you can call toString on it.

The reason why it has both value() and values() is because a field can have several values for it indexed (for example, an array of values). So, when stored, you can get the list of values associated with it (in which case, the value method will just return the first one). The reason its a List is because it maintains the order of the values indexed.On Friday, March 11, 2011 at 5:09 PM, K.B. wrote:

Hello,

when I get back a SearchHit hit, I can get back the fields with
hit.getFields();

This leads to a Map<String, SearchHitField> where String is the name
of the field and SearchHitField actually is an Interface just having:

String name();
Object value();
List values();

(plus getters with get..);

Actually is there a special reason there is no Map<String, String>
hit.getSimpleFields(); or sth. like that in it as I don*t see the
reason to get back a map of Objects that contains the key as String
name plus and Object Value that is the content of the field (the idea
with List seems bit strange to me - either I get back an
Object thst is instance of List or not - but a List is actually an
Object when it exists as List itself is just a specialized interface
derived from Collection - so, this is not good in terms of OO imho);

Best