# JDBC river query results collapsing to JSON issue
**URL:** https://discuss.elastic.co/t/jdbc-river-query-results-collapsing-to-json-issue/17126
**Category:** Elasticsearch
**Created:** [April 22, 2014, 2:35pm UTC](https://discuss.elastic.co/t/jdbc-river-query-results-collapsing-to-json-issue/17126 "2014-04-22T14:35:05Z")
**Posts on this page:** 10
**Page:** 1
### Author:  [@jrizzi1](https://discuss.elastic.co/u/jrizzi1)
#### Post date: [April 22, 2014, 2:35pm UTC](https://discuss.elastic.co/t/jdbc-river-query-results-collapsing-to-json-issue/17126/1 "2014-04-22T14:35:05Z")
I am having an issue with the jdbc river collapsing during the bulk insert
i have records that have some single value properties, and can have multiple value properties (names, addresses and emails)
there are a total of around 4.5 million rows that collapse down to 600k
if the river sql criteria is set to be where id="001", it works fine
but during the bulk process ie all of my rows, only one property that can have multiple values is correct, other properties are missing data
here is an example of what the query output that the river is using to collapse to JSON
it has 2 middle names, 2 last names, and 4 addresses
\_id pref\_mail\_name pref\_class\_year record\_status\_code first\_name middle\_name last\_name street1 street2 street3 city state\_code zipcode email\_address
0000003934 Kelly A. Draper 1999 A Kelly Ann Draper 13679 Stoney Springs Dr Chardon OH 44024-8918 [kelly\_a\_draper@yahoo.com](mailto:kelly_a_draper@yahoo.com)
0000003934 Kelly A. Draper 1999 A Kelly Ann Draper 1400 McDonald Investment Ctr 800 Superior Ave E Ste 1400 Cleveland OH 44114-2617 [kelly\_a\_draper@yahoo.com](mailto:kelly_a_draper@yahoo.com)
0000003934 Kelly A. Draper 1999 A Kelly Ann Draper 13156 Aldenshire Dr Chardon OH 44024-8921 [kelly\_a\_draper@yahoo.com](mailto:kelly_a_draper@yahoo.com)
0000003934 Kelly A. Draper 1999 A Kelly Ann Draper 100 7th Ave Ste 150 Chardon OH 44024-7808 [kelly\_a\_draper@yahoo.com](mailto:kelly_a_draper@yahoo.com)
0000003934 Kelly A. Draper 1999 A Kelly Ann Draper 13765 Equestrian Dr Burton OH 44021-9552 [kelly\_a\_draper@yahoo.com](mailto:kelly_a_draper@yahoo.com)
0000003934 Kelly A. Draper 1999 A Kelly A. McElroy 13679 Stoney Springs Dr Chardon OH 44024-8918 [kelly\_a\_draper@yahoo.com](mailto:kelly_a_draper@yahoo.com)
0000003934 Kelly A. Draper 1999 A Kelly A. McElroy 1400 McDonald Investment Ctr 800 Superior Ave E Ste 1400 Cleveland OH 44114-2617 [kelly\_a\_draper@yahoo.com](mailto:kelly_a_draper@yahoo.com)
0000003934 Kelly A. Draper 1999 A Kelly A. McElroy 13156 Aldenshire Dr Chardon OH 44024-8921 [kelly\_a\_draper@yahoo.com](mailto:kelly_a_draper@yahoo.com)
0000003934 Kelly A. Draper 1999 A Kelly A. McElroy 100 7th Ave Ste 150 Chardon OH 44024-7808 [kelly\_a\_draper@yahoo.com](mailto:kelly_a_draper@yahoo.com)
0000003934 Kelly A. Draper 1999 A Kelly A. McElroy 13765 Equestrian Dr Burton OH 44021-9552 [kelly\_a\_draper@yahoo.com](mailto:kelly_a_draper@yahoo.com)
after a river run, the indexed doc has 4 addresses, but only one middle name and one last name, the other never was indexed
"\_source": {
"pref\_mail\_name": "Kelly A. Draper",
"street2": [
" ",
"800 Superior Ave E Ste 1400"
],
"street1": [
"13679 Stoney Springs Dr",
"1400 McDonald Investment Ctr",
"13156 Aldenshire Dr",
"100 7th Ave Ste 150",
"13765 Equestrian Dr"
],
"state\_code": "OH",
"middle\_name": "A.",
"zipcode": [
"44024-8918",
"44114-2617",
"44024-8921",
"44024-7808",
"44021-9552"
],
"pref\_class\_year": "1999",
"record\_status\_code": "A",
"city": [
"Chardon",
"Cleveland",
"Burton"
],
"first\_name": "Kelly",
"last\_name": "McElroy",
"street3": " ",
"email\_address": "kelly\_a\_draper@yahoo.com"
}
}
I have attempted using bracket notation for creating objects, but the same issue exists, only now the properties are nested
my river looks like this
PUT /\_river/matcher/\_meta
{
"type" : "jdbc",
"jdbc" : {
"url" : "serverurl",
"user" : "USER",
"password" : "#########",
"sql" : "select e.id\_number as "\_id", e.pref\_mail\_name as "pref\_mail\_name", e.pref\_class\_year as "pref\_class\_year", e.record\_status\_code as "record\_status\_code", a.street1 as "street1", a.street2 as "street2", a.street3 as "street3", a.city as "city", a.state\_code as "state\_code", a.zipcode as "zipcode", n.first\_name as "first\_name", n.middle\_name as "middle\_name", n.last\_name as "last\_name", email.email\_address as "email\_address" from entity e left join name n on e.id\_number = n.id\_number left join email on e.id\_number = email.id\_number left join address a on e.id\_number = a.id\_number where e.person\_or\_org = 'P' and e.record\_status\_code IN ('A', 'L', 'D') ",
"index" : "matcher",
"type" : "entity",
"bulk\_size" : 160,
"max\_bulk\_requests" : 5
}
}
let me know if i can provide additional info
---
### Author:  [@jprante](https://discuss.elastic.co/u/jprante)
#### Post date: [April 22, 2014, 4:52pm UTC](https://discuss.elastic.co/t/jdbc-river-query-results-collapsing-to-json-issue/17126/2 "2014-04-22T16:52:12Z")
From what I understand, you want a single ES document with name:address
relations as 1:N relation, where the only ID available is for the name
(here in the example: 0000003934 for Kelly A. Draper).
It would help to define more identifiers for each address also, so you
could index the addresses in one index, and person names in the other
index, with two rivers.
The support for nested objects in SQL pseudo column bracket notation is
somewhat limited in JDBC river. If anyone feels like improving this,
patches/pull requests would be very welcome!
At the moment I feel without any identifiers or given enumeration scheme,
it is impossible to identify a sequence of JSON objects in a nested
document that can be collapsed/grouped.
Jörg
On Tue, Apr 22, 2014 at 4:35 PM, jrizzi1 [jrizzi1@nd.edu](mailto:jrizzi1@nd.edu) wrote:
> I am having an issue with the jdbc river collapsing during the bulk insert
>
> i have records that have some single value properties, and can have
> multiple
> value properties (names, addresses and emails)
>
> there are a total of around 4.5 million rows that collapse down to 600k
>
> if the river sql criteria is set to be where id="001", it works fine
>
> but during the bulk process ie all of my rows, only one property that can
> have multiple values is correct, other properties are missing data
>
> here is an example of what the query output that the river is using to
> collapse to JSON
> it has 2 middle names, 2 last names, and 4 addresses
>
> \_id pref\_mail\_name pref\_class\_year record\_status\_code first\_name
> middle\_name
> last\_name street1 street2 street3 city state\_code zipcode
> email\_address
> 0000003934 Kelly A. Draper 1999 A Kelly Ann Draper
> 13679 Stoney Springs Dr
> Chardon OH 44024-8918 [kelly\_a\_draper@yahoo.com](mailto:kelly_a_draper@yahoo.com)
> 0000003934 Kelly A. Draper 1999 A Kelly Ann Draper
> 1400 McDonald Investment
> Ctr 800 Superior Ave E Ste 1400 Cleveland OH
> 44114-2617
> [kelly\_a\_draper@yahoo.com](mailto:kelly_a_draper@yahoo.com)
> 0000003934 Kelly A. Draper 1999 A Kelly Ann Draper
> 13156 Aldenshire Dr
> Chardon OH 44024-8921 [kelly\_a\_draper@yahoo.com](mailto:kelly_a_draper@yahoo.com)
> 0000003934 Kelly A. Draper 1999 A Kelly Ann Draper
> 100 7th Ave Ste 150
> Chardon OH 44024-7808 [kelly\_a\_draper@yahoo.com](mailto:kelly_a_draper@yahoo.com)
> 0000003934 Kelly A. Draper 1999 A Kelly Ann Draper
> 13765 Equestrian Dr
> Burton OH 44021-9552 [kelly\_a\_draper@yahoo.com](mailto:kelly_a_draper@yahoo.com)
> 0000003934 Kelly A. Draper 1999 A Kelly A. McElroy
> 13679 Stoney Springs Dr
> Chardon OH 44024-8918 [kelly\_a\_draper@yahoo.com](mailto:kelly_a_draper@yahoo.com)
> 0000003934 Kelly A. Draper 1999 A Kelly A. McElroy
> 1400 McDonald Investment
> Ctr 800 Superior Ave E Ste 1400 Cleveland OH
> 44114-2617
> [kelly\_a\_draper@yahoo.com](mailto:kelly_a_draper@yahoo.com)
> 0000003934 Kelly A. Draper 1999 A Kelly A. McElroy
> 13156 Aldenshire Dr
> Chardon OH 44024-8921 [kelly\_a\_draper@yahoo.com](mailto:kelly_a_draper@yahoo.com)
> 0000003934 Kelly A. Draper 1999 A Kelly A. McElroy
> 100 7th Ave Ste 150
> Chardon OH 44024-7808 [kelly\_a\_draper@yahoo.com](mailto:kelly_a_draper@yahoo.com)
> 0000003934 Kelly A. Draper 1999 A Kelly A. McElroy
> 13765 Equestrian Dr
> Burton OH 44021-9552 [kelly\_a\_draper@yahoo.com](mailto:kelly_a_draper@yahoo.com)
>
> after a river run, the indexed doc has 4 addresses, but only one middle
> name
> and one last name, the other never was indexed
>
> "\_source": {
> "pref\_mail\_name": "Kelly A. Draper",
> "street2": [
> " ",
> "800 Superior Ave E Ste 1400"
> ],
> "street1": [
> "13679 Stoney Springs Dr",
> "1400 McDonald Investment Ctr",
> "13156 Aldenshire Dr",
> "100 7th Ave Ste 150",
> "13765 Equestrian Dr"
> ],
> "state\_code": "OH",
> "middle\_name": "A.",
> "zipcode": [
> "44024-8918",
> "44114-2617",
> "44024-8921",
> "44024-7808",
> "44021-9552"
> ],
> "pref\_class\_year": "1999",
> "record\_status\_code": "A",
> "city": [
> "Chardon",
> "Cleveland",
> "Burton"
> ],
> "first\_name": "Kelly",
> "last\_name": "McElroy",
> "street3": " ",
> "email\_address": "[kelly\_a\_draper@yahoo.com](mailto:kelly_a_draper@yahoo.com)"
> }
> }
>
> I have attempted using bracket notation for creating objects, but the same
> issue exists, only now the properties are nested
>
> my river looks like this
>
> PUT /\_river/matcher/\_meta
> {
> "type" : "jdbc",
> "jdbc" : {
> "url" : "serverurl",
> "user" : "USER",
> "password" : "#########",
> "sql" : "select e.id\_number as "\_id", e.pref\_mail\_name as
> "pref\_mail\_name", e.pref\_class\_year as "pref\_class\_year",
> e.record\_status\_code as "record\_status\_code", a.street1 as "street1",
> a.street2 as "street2", a.street3 as "street3", a.city as "city",
> a.state\_code as "state\_code", a.zipcode as "zipcode", n.first\_name as
> "first\_name", n.middle\_name as "middle\_name", n.last\_name as
> "last\_name", email.email\_address as "email\_address" from entity e left
> join name n on e.id\_number = n.id\_number left join email on e.id\_number =
> email.id\_number left join address a on e.id\_number = a.id\_number where
> e.person\_or\_org = 'P' and e.record\_status\_code IN ('A', 'L', 'D') ",
> "index" : "matcher",
> "type" : "entity",
> "bulk\_size" : 160,
> "max\_bulk\_requests" : 5
> }
> }
>
> let me know if i can provide additional info
>
> --
> View this message in context:
> [http://elasticsearch-users.115913.n3.nabble.com/JDBC-river-query-results-collapsing-to-JSON-issue-tp4054562.html](http://elasticsearch-users.115913.n3.nabble.com/JDBC-river-query-results-collapsing-to-JSON-issue-tp4054562.html)
> Sent from the Elasticsearch Users mailing list archive at [Nabble.com](http://Nabble.com).
>
> --
> You received this message because you are subscribed to the Google Groups
> "elasticsearch" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).
> To view this discussion on the web visit
> [https://groups.google.com/d/msgid/elasticsearch/1398177305643-4054562.post%40n3.nabble.com](https://groups.google.com/d/msgid/elasticsearch/1398177305643-4054562.post%40n3.nabble.com)
> .
> For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).
To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAKdsXoHk7-%3Dj%2BQAFPPy%3Dw4%2BiXD%3D%3Dx2BT%2Bao%2BLQQ0DB-hjKiHgw%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAKdsXoHk7-%3Dj%2BQAFPPy%3Dw4%2BiXD%3D%3Dx2BT%2Bao%2BLQQ0DB-hjKiHgw%40mail.gmail.com).
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
---
### Author:  [@jrizzi1](https://discuss.elastic.co/u/jrizzi1)
#### Post date: [April 22, 2014, 6:53pm UTC](https://discuss.elastic.co/t/jdbc-river-query-results-collapsing-to-json-issue/17126/3 "2014-04-22T18:53:29Z")
Hi Jorg,
I wanted a single ES document, i have a primary table that has unique id's and the names is a 1:N relation, and the address is a 1:N relation
reason being is we will need to search on names and addresses to try to find the unique ID for the individual so we can do further processing
how could I search over several indicies and merge those results back together to give the one unique id that best matches? my initial test of splitting these apart into different indicies is showing addresses and entities littered in the same result set, i havent any idea how to get a commonality between them
the addresses and names dont really have unique identifiers of their own, they are sequenced by the primary ID, example: if the primary table ID is '1001', and he has three addresses then the unqiue ID for those rows would be id='1001', sequence='1', id='1001', sequence='2', ... etc
---
### Author:  [@jprante](https://discuss.elastic.co/u/jprante)
#### Post date: [April 22, 2014, 7:05pm UTC](https://discuss.elastic.co/t/jdbc-river-query-results-collapsing-to-json-issue/17126/4 "2014-04-22T19:05:24Z")
Have you tried parent/child ?
The idea is to execute has\_parent queries on address type to find parent ID
> **[Elasticsearch Platform — Find real-time answers at scale](https://www.elastic.co)**
>
> Power insights and outcomes with the Elasticsearch Platform and AI. See into your data and find answers that matter with enterprise solutions designed to help you build, observe, and protect. Try Elasticsearch free today.
I can prepare an example ...
Jörg
On Tue, Apr 22, 2014 at 8:53 PM, jrizzi1 [jrizzi1@nd.edu](mailto:jrizzi1@nd.edu) wrote:
> Hi Jorg,
>
> I wanted a single ES document, i have a primary table that has unique id's
> and the names is a 1:N relation, and the address is a 1:N relation
>
> reason being is we will need to search on names and addresses to try to
> find
> the unique ID for the individual so we can do further processing
>
> how could I search over several indicies and merge those results back
> together to give the one unique id that best matches? my initial test of
> splitting these apart into different indicies is showing addresses and
> entities littered in the same result set, i havent any idea how to get a
> commonality between them
>
> the addresses and names dont really have unique identifiers of their own,
> they are sequenced by the primary ID, example: if the primary table ID is
> '1001', and he has three addresses then the unqiue ID for those rows would
> be id='1001', sequence='1', id='1001', sequence='2', ... etc
>
> --
> View this message in context:
> [http://elasticsearch-users.115913.n3.nabble.com/JDBC-river-query-results-collapsing-to-JSON-issue-tp4054562p4054576.html](http://elasticsearch-users.115913.n3.nabble.com/JDBC-river-query-results-collapsing-to-JSON-issue-tp4054562p4054576.html)
> Sent from the Elasticsearch Users mailing list archive at [Nabble.com](http://Nabble.com).
>
> --
> You received this message because you are subscribed to the Google Groups
> "elasticsearch" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).
> To view this discussion on the web visit
> [https://groups.google.com/d/msgid/elasticsearch/1398192809993-4054576.post%40n3.nabble.com](https://groups.google.com/d/msgid/elasticsearch/1398192809993-4054576.post%40n3.nabble.com)
> .
> For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).
To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAKdsXoHtndn4q2NZWHXA9mBiuA44Pc1NH4OZVn9C1u%3DSmfom4w%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAKdsXoHtndn4q2NZWHXA9mBiuA44Pc1NH4OZVn9C1u%3DSmfom4w%40mail.gmail.com).
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
---
### Author:  [@jprante](https://discuss.elastic.co/u/jprante)
#### Post date: [April 22, 2014, 7:30pm UTC](https://discuss.elastic.co/t/jdbc-river-query-results-collapsing-to-json-issue/17126/5 "2014-04-22T19:30:47Z")
Is this parent/child example sketching the challenge you are facing?
>
Jörg
On Tue, Apr 22, 2014 at 9:05 PM, [joergprante@gmail.com](mailto:joergprante@gmail.com) \<
[joergprante@gmail.com](mailto:joergprante@gmail.com)\> wrote:
> Have you tried parent/child ?
>
> The idea is to execute has\_parent queries on address type to find parent
> ID
> [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/query-dsl-has-parent-query.html)
>
> I can prepare an example ...
>
> Jörg
>
> On Tue, Apr 22, 2014 at 8:53 PM, jrizzi1 [jrizzi1@nd.edu](mailto:jrizzi1@nd.edu) wrote:
>
> > Hi Jorg,
> >
> > I wanted a single ES document, i have a primary table that has unique id's
> > and the names is a 1:N relation, and the address is a 1:N relation
> >
> > reason being is we will need to search on names and addresses to try to
> > find
> > the unique ID for the individual so we can do further processing
> >
> > how could I search over several indicies and merge those results back
> > together to give the one unique id that best matches? my initial test of
> > splitting these apart into different indicies is showing addresses and
> > entities littered in the same result set, i havent any idea how to get a
> > commonality between them
> >
> > the addresses and names dont really have unique identifiers of their own,
> > they are sequenced by the primary ID, example: if the primary table ID is
> > '1001', and he has three addresses then the unqiue ID for those rows would
> > be id='1001', sequence='1', id='1001', sequence='2', ... etc
> >
> > --
> > View this message in context:
> > [http://elasticsearch-users.115913.n3.nabble.com/JDBC-river-query-results-collapsing-to-JSON-issue-tp4054562p4054576.html](http://elasticsearch-users.115913.n3.nabble.com/JDBC-river-query-results-collapsing-to-JSON-issue-tp4054562p4054576.html)
> > Sent from the Elasticsearch Users mailing list archive at [Nabble.com](http://Nabble.com).
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "elasticsearch" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).
> > To view this discussion on the web visit
> > [https://groups.google.com/d/msgid/elasticsearch/1398192809993-4054576.post%40n3.nabble.com](https://groups.google.com/d/msgid/elasticsearch/1398192809993-4054576.post%40n3.nabble.com)
> > .
> > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).
To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAKdsXoFVBChBiNcCWFYU-WcPFnYCC1\_jD1iu57ZvLwDnn-x%3DeA%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAKdsXoFVBChBiNcCWFYU-WcPFnYCC1_jD1iu57ZvLwDnn-x%3DeA%40mail.gmail.com).
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
---
### Author:  [@jrizzi1](https://discuss.elastic.co/u/jrizzi1)
#### Post date: [April 22, 2014, 8:05pm UTC](https://discuss.elastic.co/t/jdbc-river-query-results-collapsing-to-json-issue/17126/6 "2014-04-22T20:05:42Z")
Thank you for that gist, it really helps to see a full setup like that from start to finish
I had attempted originally a parent-child relationship for this data by using \_parent in separate river(s), but decided to go to a single index because when I attempted to return child information you can only return parent properties not children properties as well in the hits, and wasnt sure how to additionally query to get child property data
but reality is I more than likely need to switch to this setup to retain all of my data, which is the least of all evils
Is this parent/child example sketching the challenge you are facing?
>
Jörg
On Tue, Apr 22, 2014 at 9:05 PM, joergprante@ \<
joergprante@\> wrote:
> Have you tried parent/child ?
>
> The idea is to execute has\_parent queries on address type to find parent
> ID
> [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/query-dsl-has-parent-query.html)
>
> I can prepare an example ...
>
> Jörg
>
> On Tue, Apr 22, 2014 at 8:53 PM, jrizzi1 \ wrote:
>
> > Hi Jorg,
> >
> > I wanted a single ES document, i have a primary table that has unique id's
> > and the names is a 1:N relation, and the address is a 1:N relation
> >
> > reason being is we will need to search on names and addresses to try to
> > find
> > the unique ID for the individual so we can do further processing
> >
> > how could I search over several indicies and merge those results back
> > together to give the one unique id that best matches? my initial test of
> > splitting these apart into different indicies is showing addresses and
> > entities littered in the same result set, i havent any idea how to get a
> > commonality between them
> >
> > the addresses and names dont really have unique identifiers of their own,
> > they are sequenced by the primary ID, example: if the primary table ID is
> > '1001', and he has three addresses then the unqiue ID for those rows would
> > be id='1001', sequence='1', id='1001', sequence='2', ... etc
> >
> > --
> > View this message in context:
> > [http://elasticsearch-users.115913.n3.nabble.com/JDBC-river-query-results-collapsing-to-JSON-issue-tp4054562p4054576.html](http://elasticsearch-users.115913.n3.nabble.com/JDBC-river-query-results-collapsing-to-JSON-issue-tp4054562p4054576.html)
> > Sent from the Elasticsearch Users mailing list archive at [Nabble.com](http://Nabble.com).
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "elasticsearch" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to elasticsearch+unsubscribe@.
> > To view this discussion on the web visit
> > [https://groups.google.com/d/msgid/elasticsearch/1398192809993-4054576.post%40n3.nabble.com](https://groups.google.com/d/msgid/elasticsearch/1398192809993-4054576.post%40n3.nabble.com)
> > .
> > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@.
To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAKdsXoFVBChBiNcCWFYU-WcPFnYCC1\_jD1iu57ZvLwDnn-x%3DeA%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAKdsXoFVBChBiNcCWFYU-WcPFnYCC1_jD1iu57ZvLwDnn-x%3DeA%40mail.gmail.com).
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
---
### Author:  [@jprante](https://discuss.elastic.co/u/jprante)
#### Post date: [April 22, 2014, 8:11pm UTC](https://discuss.elastic.co/t/jdbc-river-query-results-collapsing-to-json-issue/17126/7 "2014-04-22T20:11:25Z")
I see the use case for building deep nested docs from JDBC river (and other
data sources).
In JDBC river, there are open questions about nested result sets, which is
similar.
I have to think more about multiple SQL statements and create "merge
points" to construct bigger JSON from them in a natural way...
Jörg
On Tue, Apr 22, 2014 at 10:05 PM, jrizzi1 [jrizzi1@nd.edu](mailto:jrizzi1@nd.edu) wrote:
> Thank you for that gist, it really helps to see a full setup like that from
> start to finish
>
> I had attempted originally a parent-child relationship for this data by
> using \_parent in separate river(s), but decided to go to a single index
> because when I attempted to return child information you can only return
> parent properties not children properties as well in the hits, and wasnt
> sure how to additionally query to get child property data
>
> but reality is I more than likely need to switch to this setup to retain
> all
> of my data, which is the least of all evils
>
> [joergprante@gmail.com](mailto:joergprante@gmail.com) wrote
>
> > Is this parent/child example sketching the challenge you are facing?
> >
> > [Person/address relation as parent/child for Elasticsearch · GitHub](https://gist.github.com/jprante/11191387)
> >
> > Jörg
> >
> > On Tue, Apr 22, 2014 at 9:05 PM,
>
> > joergprante@
>
> > \<
>
> > joergprante@
>
> > > wrote:
> >
> > > Have you tried parent/child ?
> > >
> > > The idea is to execute has\_parent queries on address type to find parent
> > > ID
>
> [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/query-dsl-has-parent-query.html)
>
> > > I can prepare an example ...
> > >
> > > Jörg
> > >
> > > On Tue, Apr 22, 2014 at 8:53 PM, jrizzi1 \<
>
> > jrizzi1@
>
> > \> wrote:
> >
> > > > Hi Jorg,
> > > >
> > > > I wanted a single ES document, i have a primary table that has unique
> > > > id's
> > > > and the names is a 1:N relation, and the address is a 1:N relation
> > > >
> > > > reason being is we will need to search on names and addresses to try to
> > > > find
> > > > the unique ID for the individual so we can do further processing
> > > >
> > > > how could I search over several indicies and merge those results back
> > > > together to give the one unique id that best matches? my initial test
> > > > of
> > > > splitting these apart into different indicies is showing addresses and
> > > > entities littered in the same result set, i havent any idea how to get
> > > > a
> > > > commonality between them
> > > >
> > > > the addresses and names dont really have unique identifiers of their
> > > > own,
> > > > they are sequenced by the primary ID, example: if the primary table ID
> > > > is
> > > > '1001', and he has three addresses then the unqiue ID for those rows
> > > > would
> > > > be id='1001', sequence='1', id='1001', sequence='2', ... etc
> > > >
> > > > --
> > > > View this message in context:
>
> [http://elasticsearch-users.115913.n3.nabble.com/JDBC-river-query-results-collapsing-to-JSON-issue-tp4054562p4054576.html](http://elasticsearch-users.115913.n3.nabble.com/JDBC-river-query-results-collapsing-to-JSON-issue-tp4054562p4054576.html)
>
> > > > Sent from the Elasticsearch Users mailing list archive at [Nabble.com](http://Nabble.com).
> > > >
> > > > --
> > > > You received this message because you are subscribed to the Google
> > > > Groups
> > > > "elasticsearch" group.
> > > > To unsubscribe from this group and stop receiving emails from it, send
> > > > an
> > > > email to
>
> > elasticsearch+unsubscribe@
>
> > .
> >
> > > > To view this discussion on the web visit
>
> [https://groups.google.com/d/msgid/elasticsearch/1398192809993-4054576.post%40n3.nabble.com](https://groups.google.com/d/msgid/elasticsearch/1398192809993-4054576.post%40n3.nabble.com)
>
> > > > .
> > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "elasticsearch" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to
>
> > elasticsearch+unsubscribe@
>
> > .
> > To view this discussion on the web visit
>
> [https://groups.google.com/d/msgid/elasticsearch/CAKdsXoFVBChBiNcCWFYU-WcPFnYCC1\_jD1iu57ZvLwDnn-x%3DeA%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAKdsXoFVBChBiNcCWFYU-WcPFnYCC1_jD1iu57ZvLwDnn-x%3DeA%40mail.gmail.com)
> .
>
> > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
>
> --
> View this message in context:
> [http://elasticsearch-users.115913.n3.nabble.com/JDBC-river-query-results-collapsing-to-JSON-issue-tp4054562p4054581.html](http://elasticsearch-users.115913.n3.nabble.com/JDBC-river-query-results-collapsing-to-JSON-issue-tp4054562p4054581.html)
> Sent from the Elasticsearch Users mailing list archive at [Nabble.com](http://Nabble.com).
>
> --
> You received this message because you are subscribed to the Google Groups
> "elasticsearch" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).
> To view this discussion on the web visit
> [https://groups.google.com/d/msgid/elasticsearch/1398197142689-4054581.post%40n3.nabble.com](https://groups.google.com/d/msgid/elasticsearch/1398197142689-4054581.post%40n3.nabble.com)
> .
> For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).
To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAKdsXoGuj9CnYeVvTuYtjrmb2U00seunUbCvrnEzwdojaEEOBQ%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAKdsXoGuj9CnYeVvTuYtjrmb2U00seunUbCvrnEzwdojaEEOBQ%40mail.gmail.com).
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
---
### Author:  [@jrizzi1](https://discuss.elastic.co/u/jrizzi1)
#### Post date: [April 23, 2014, 1:44pm UTC](https://discuss.elastic.co/t/jdbc-river-query-results-collapsing-to-json-issue/17126/8 "2014-04-23T13:44:52Z")
That sounds like good news, looking forward to that
The only thing that really bothers me about the issue originally listed is that the \_river results will collapse to JSON correctly with multiple 1:N relationships if i \_river a smaller dataset
for instance , if i include in my \_river sql criteria like "where id \<= 4000" , the sql results are 25k rows that get collapsed into 3000 documents indexed, and 1:N data is correct, at least from spot checking over 40 docs with multiple 1:N data
It is only when i do larger sql results that some 1:N data goes missing, which leads me to believe that something is occurring in the bulk process , right?
I see the use case for building deep nested docs from JDBC river (and other data sources).
In JDBC river, there are open questions about nested result sets, which is
similar.
I have to think more about multiple SQL statements and create "merge
points" to construct bigger JSON from them in a natural way...
Jörg
On Tue, Apr 22, 2014 at 10:05 PM, jrizzi1 \ wrote:
> Thank you for that gist, it really helps to see a full setup like that from
> start to finish
>
> I had attempted originally a parent-child relationship for this data by
> using \_parent in separate river(s), but decided to go to a single index
> because when I attempted to return child information you can only return
> parent properties not children properties as well in the hits, and wasnt
> sure how to additionally query to get child property data
>
> but reality is I more than likely need to switch to this setup to retain
> all
> of my data, which is the least of all evils
>
> joergprante@ wrote
>
> > Is this parent/child example sketching the challenge you are facing?
> >
> > [Person/address relation as parent/child for Elasticsearch · GitHub](https://gist.github.com/jprante/11191387)
> >
> > Jörg
> >
> > On Tue, Apr 22, 2014 at 9:05 PM,
>
> > joergprante@
>
> > \<
>
> > joergprante@
>
> > > wrote:
> >
> > > Have you tried parent/child ?
> > >
> > > The idea is to execute has\_parent queries on address type to find parent
> > > ID
>
> [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/query-dsl-has-parent-query.html)
>
> > > I can prepare an example ...
> > >
> > > Jörg
> > >
> > > On Tue, Apr 22, 2014 at 8:53 PM, jrizzi1 \<
>
> > jrizzi1@
>
> > \> wrote:
> >
> > > > Hi Jorg,
> > > >
> > > > I wanted a single ES document, i have a primary table that has unique
> > > > id's
> > > > and the names is a 1:N relation, and the address is a 1:N relation
> > > >
> > > > reason being is we will need to search on names and addresses to try to
> > > > find
> > > > the unique ID for the individual so we can do further processing
> > > >
> > > > how could I search over several indicies and merge those results back
> > > > together to give the one unique id that best matches? my initial test
> > > > of
> > > > splitting these apart into different indicies is showing addresses and
> > > > entities littered in the same result set, i havent any idea how to get
> > > > a
> > > > commonality between them
> > > >
> > > > the addresses and names dont really have unique identifiers of their
> > > > own,
> > > > they are sequenced by the primary ID, example: if the primary table ID
> > > > is
> > > > '1001', and he has three addresses then the unqiue ID for those rows
> > > > would
> > > > be id='1001', sequence='1', id='1001', sequence='2', ... etc
> > > >
> > > > --
> > > > View this message in context:
>
> [http://elasticsearch-users.115913.n3.nabble.com/JDBC-river-query-results-collapsing-to-JSON-issue-tp4054562p4054576.html](http://elasticsearch-users.115913.n3.nabble.com/JDBC-river-query-results-collapsing-to-JSON-issue-tp4054562p4054576.html)
>
> > > > Sent from the Elasticsearch Users mailing list archive at [Nabble.com](http://Nabble.com).
> > > >
> > > > --
> > > > You received this message because you are subscribed to the Google
> > > > Groups
> > > > "elasticsearch" group.
> > > > To unsubscribe from this group and stop receiving emails from it, send
> > > > an
> > > > email to
>
> > elasticsearch+unsubscribe@
>
> > .
> >
> > > > To view this discussion on the web visit
>
> [https://groups.google.com/d/msgid/elasticsearch/1398192809993-4054576.post%40n3.nabble.com](https://groups.google.com/d/msgid/elasticsearch/1398192809993-4054576.post%40n3.nabble.com)
>
> > > > .
> > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "elasticsearch" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to
>
> > elasticsearch+unsubscribe@
>
> > .
> > To view this discussion on the web visit
>
> [https://groups.google.com/d/msgid/elasticsearch/CAKdsXoFVBChBiNcCWFYU-WcPFnYCC1\_jD1iu57ZvLwDnn-x%3DeA%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAKdsXoFVBChBiNcCWFYU-WcPFnYCC1_jD1iu57ZvLwDnn-x%3DeA%40mail.gmail.com)
> .
>
> > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
>
> --
> View this message in context:
> [http://elasticsearch-users.115913.n3.nabble.com/JDBC-river-query-results-collapsing-to-JSON-issue-tp4054562p4054581.html](http://elasticsearch-users.115913.n3.nabble.com/JDBC-river-query-results-collapsing-to-JSON-issue-tp4054562p4054581.html)
> Sent from the Elasticsearch Users mailing list archive at [Nabble.com](http://Nabble.com).
>
> --
> You received this message because you are subscribed to the Google Groups
> "elasticsearch" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elasticsearch+unsubscribe@.
> To view this discussion on the web visit
> [https://groups.google.com/d/msgid/elasticsearch/1398197142689-4054581.post%40n3.nabble.com](https://groups.google.com/d/msgid/elasticsearch/1398197142689-4054581.post%40n3.nabble.com)
> .
> For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@.
To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAKdsXoGuj9CnYeVvTuYtjrmb2U00seunUbCvrnEzwdojaEEOBQ%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAKdsXoGuj9CnYeVvTuYtjrmb2U00seunUbCvrnEzwdojaEEOBQ%40mail.gmail.com).
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
---
### Author:  [@jprante](https://discuss.elastic.co/u/jprante)
#### Post date: [April 23, 2014, 4:41pm UTC](https://discuss.elastic.co/t/jdbc-river-query-results-collapsing-to-json-issue/17126/9 "2014-04-23T16:41:07Z")
I hesitate to add "oversophisticated" code to the JDBC river that collapses
without reason.
Somehow the definition should set "merge points" to control the zone of
JSON object/array growth. Maybe an extension of the bracket notation is all
that is needed.
At least, I will add extensive logging to the river so it can be traced
easily how the JSON docs are built from SQL.
Jörg
On Wed, Apr 23, 2014 at 3:44 PM, jrizzi1 [jrizzi1@nd.edu](mailto:jrizzi1@nd.edu) wrote:
> That sounds like good news, looking forward to that
>
> The only thing that really bothers me about the issue originally listed is
> that the \_river results will collapse to JSON correctly with multiple 1:N
> relationships if i \_river a smaller dataset
>
> for instance , if i include in my \_river sql criteria like "where id \<=
> 4000" , the sql results are 25k rows that get collapsed into 3000 documents
> indexed, and 1:N data is correct, at least from spot checking over 40 docs
> with multiple 1:N data
>
> It is only when i do larger sql results that some 1:N data goes missing,
> which leads me to believe that something is occurring in the bulk process ,
> right?
>
> [joergprante@gmail.com](mailto:joergprante@gmail.com) wrote
>
> > I see the use case for building deep nested docs from JDBC river (and
> > other
> > data sources).
> >
> > In JDBC river, there are open questions about nested result sets, which
> > is
> > similar.
> >
> > I have to think more about multiple SQL statements and create "merge
> > points" to construct bigger JSON from them in a natural way...
> >
> > Jörg
> >
> > On Tue, Apr 22, 2014 at 10:05 PM, jrizzi1 \<
>
> > jrizzi1@
>
> > \> wrote:
> >
> > > Thank you for that gist, it really helps to see a full setup like that
> > > from
> > > start to finish
> > >
> > > I had attempted originally a parent-child relationship for this data by
> > > using \_parent in separate river(s), but decided to go to a single index
> > > because when I attempted to return child information you can only return
> > > parent properties not children properties as well in the hits, and wasnt
> > > sure how to additionally query to get child property data
> > >
> > > but reality is I more than likely need to switch to this setup to retain
> > > all
> > > of my data, which is the least of all evils
>
> > joergprante@
>
> > wrote
> >
> > > > Is this parent/child example sketching the challenge you are facing?
> > > >
> > > > [Person/address relation as parent/child for Elasticsearch · GitHub](https://gist.github.com/jprante/11191387)
> > > >
> > > > Jörg
> > > >
> > > > On Tue, Apr 22, 2014 at 9:05 PM,
> > >
> > > > joergprante@
> > >
> > > > \<
> > >
> > > > joergprante@
> > >
> > > > > wrote:
> > > >
> > > > > Have you tried parent/child ?
> > > > >
> > > > > The idea is to execute has\_parent queries on address type to find
> > > > > parent
> > > > > ID
>
> [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/query-dsl-has-parent-query.html)
>
> > > > > I can prepare an example ...
> > > > >
> > > > > Jörg
> > > > >
> > > > > On Tue, Apr 22, 2014 at 8:53 PM, jrizzi1 \<
> > >
> > > > jrizzi1@
> > >
> > > > \> wrote:
> > > >
> > > > > > Hi Jorg,
> > > > > >
> > > > > > I wanted a single ES document, i have a primary table that has
> > > > > > unique
> > > > > > id's
> > > > > > and the names is a 1:N relation, and the address is a 1:N relation
> > > > > >
> > > > > > reason being is we will need to search on names and addresses to try
> > > > > > to
> > > > > > find
> > > > > > the unique ID for the individual so we can do further processing
> > > > > >
> > > > > > how could I search over several indicies and merge those results
> > > > > > back
> > > > > > together to give the one unique id that best matches? my initial
> > > > > > test
> > > > > > of
> > > > > > splitting these apart into different indicies is showing addresses
> > > > > > and
> > > > > > entities littered in the same result set, i havent any idea how to
> > > > > > get
> > > > > > a
> > > > > > commonality between them
> > > > > >
> > > > > > the addresses and names dont really have unique identifiers of their
> > > > > > own,
> > > > > > they are sequenced by the primary ID, example: if the primary table
> > > > > > ID
> > > > > > is
> > > > > > '1001', and he has three addresses then the unqiue ID for those rows
> > > > > > would
> > > > > > be id='1001', sequence='1', id='1001', sequence='2', ... etc
> > > > > >
> > > > > > --
> > > > > > View this message in context:
>
> [http://elasticsearch-users.115913.n3.nabble.com/JDBC-river-query-results-collapsing-to-JSON-issue-tp4054562p4054576.html](http://elasticsearch-users.115913.n3.nabble.com/JDBC-river-query-results-collapsing-to-JSON-issue-tp4054562p4054576.html)
>
> > > > > > Sent from the Elasticsearch Users mailing list archive at
> > > > > > [Nabble.com](http://Nabble.com).
> > > > > >
> > > > > > --
> > > > > > You received this message because you are subscribed to the Google
> > > > > > Groups
> > > > > > "elasticsearch" group.
> > > > > > To unsubscribe from this group and stop receiving emails from it,
> > > > > > send
> > > > > > an
> > > > > > email to
> > >
> > > > elasticsearch+unsubscribe@
> > >
> > > > .
> > > >
> > > > > > To view this discussion on the web visit
>
> [https://groups.google.com/d/msgid/elasticsearch/1398192809993-4054576.post%40n3.nabble.com](https://groups.google.com/d/msgid/elasticsearch/1398192809993-4054576.post%40n3.nabble.com)
>
> > > > > > .
> > > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
> > > >
> > > > --
> > > > You received this message because you are subscribed to the Google
> > > > Groups
> > > > "elasticsearch" group.
> > > > To unsubscribe from this group and stop receiving emails from it, send
> > > > an
> > > > email to
> > >
> > > > elasticsearch+unsubscribe@
> > >
> > > > .
> > > > To view this discussion on the web visit
>
> [https://groups.google.com/d/msgid/elasticsearch/CAKdsXoFVBChBiNcCWFYU-WcPFnYCC1\_jD1iu57ZvLwDnn-x%3DeA%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAKdsXoFVBChBiNcCWFYU-WcPFnYCC1_jD1iu57ZvLwDnn-x%3DeA%40mail.gmail.com)
>
> > > .
> > >
> > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
> > >
> > > --
> > > View this message in context:
>
> [http://elasticsearch-users.115913.n3.nabble.com/JDBC-river-query-results-collapsing-to-JSON-issue-tp4054562p4054581.html](http://elasticsearch-users.115913.n3.nabble.com/JDBC-river-query-results-collapsing-to-JSON-issue-tp4054562p4054581.html)
>
> > > Sent from the Elasticsearch Users mailing list archive at [Nabble.com](http://Nabble.com).
> > >
> > > --
> > > You received this message because you are subscribed to the Google
> > > Groups
> > > "elasticsearch" group.
> > > To unsubscribe from this group and stop receiving emails from it, send
> > > an
> > > email to
>
> > elasticsearch+unsubscribe@
>
> > .
> >
> > > To view this discussion on the web visit
>
> [https://groups.google.com/d/msgid/elasticsearch/1398197142689-4054581.post%40n3.nabble.com](https://groups.google.com/d/msgid/elasticsearch/1398197142689-4054581.post%40n3.nabble.com)
>
> > > .
> > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "elasticsearch" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to
>
> > elasticsearch+unsubscribe@
>
> > .
> > To view this discussion on the web visit
>
> [https://groups.google.com/d/msgid/elasticsearch/CAKdsXoGuj9CnYeVvTuYtjrmb2U00seunUbCvrnEzwdojaEEOBQ%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAKdsXoGuj9CnYeVvTuYtjrmb2U00seunUbCvrnEzwdojaEEOBQ%40mail.gmail.com)
> .
>
> > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
>
> --
> View this message in context:
> [http://elasticsearch-users.115913.n3.nabble.com/JDBC-river-query-results-collapsing-to-JSON-issue-tp4054562p4054631.html](http://elasticsearch-users.115913.n3.nabble.com/JDBC-river-query-results-collapsing-to-JSON-issue-tp4054562p4054631.html)
> Sent from the Elasticsearch Users mailing list archive at [Nabble.com](http://Nabble.com).
>
> --
> You received this message because you are subscribed to the Google Groups
> "elasticsearch" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).
> To view this discussion on the web visit
> [https://groups.google.com/d/msgid/elasticsearch/1398260692324-4054631.post%40n3.nabble.com](https://groups.google.com/d/msgid/elasticsearch/1398260692324-4054631.post%40n3.nabble.com)
> .
> For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).
To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAKdsXoGbv2SqbBmXgWAgZJZ4a090yKTQFfoN\_62\_57nbxhC67Q%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAKdsXoGbv2SqbBmXgWAgZJZ4a090yKTQFfoN_62_57nbxhC67Q%40mail.gmail.com).
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
---
### Author:  [@system](https://discuss.elastic.co/u/system)
#### Post date: [July 6, 2017, 1:34am UTC](https://discuss.elastic.co/t/jdbc-river-query-results-collapsing-to-json-issue/17126/10 "2017-07-06T01:34:01Z")