> > Out of curiosity, how is this used (and in what contexts)? > I'm wondering the implications of new fields appearing when new > documents are added. Will this mess up the JDBC driver?
Currently its not being used. Select * isn't supported yet. The JDBC driver will just push down to the SQL handler. It will be in the SQL handler that we need to worry about it. Maybe on a commit or something can refresh the field list. Haven't gotten that far yet. Kevin Risden On Thu, Nov 17, 2016 at 8:05 PM, Yonik Seeley <[email protected]> wrote: > On Thu, Nov 17, 2016 at 6:54 PM, Kevin Risden <[email protected]> > wrote: > > For reference, the SQL/JDBC piece needed ability to specify wildcard and > > figure out the "schema" of the collection including defined dynamic > fields. > > Out of curiosity, how is this used (and in what contexts)? > I'm wondering the implications of new fields appearing when new > documents are added. Will this mess up the JDBC driver? > > > When testing lately with supporting "select *" type semantics, it would > be > > nice to be able to limit to only DocValues fields. > > I'm not sure we should be segregating stored fields this way (by > whether they are column/docValues or not). > By default, all of our non-text fields already have docvalues enabled. > If someone wants to retrieve or operate on row-stored text fields, it > seems like they should be able to do so via the streaming API (or > SQL). > > I guess we could also go the other direction and *only* support > docValues (i.e. scrap row-stored fields). But that seems a little > more extreme, and I'm also not sure if binary docValues would work as > well or could hold text fields of the same size as row-stored fields > can. > > -Yonik > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
