>From usability perspective, I think it's better to have options completely case insensitive (and not case preserving). Users don't necessarily care about case specifics when registering them as long as they can access them back no matter the case they use.
-Abhishek On Wed, Apr 22, 2015 at 10:16 AM, Jason Altekruse <[email protected]> wrote: > The only argument I can think of is that configuration options that end up > being passed through to other systems may be easier to deal with if we > allow for options to be defined with any case that the underlying system > expects. If it is case-sensitive, we would have to create a map from the > Drill names to the names expected by the specific component. On the other > hand, as we already define then names to loosely follow a logical hierarchy > that makes sense for Drill, it is likely that our names won't match up > anyway, for example if e need to pass configuration down to the parquet > reader we already need to map our names like store.parquet.option_name to > the parquet option names (as they don't need to specify that the option > relates to storage or parquet in the name). > > I think we can safely lowercase everything for now. > > - Jason Altekruse > > On Tue, Apr 21, 2015 at 1:03 PM, Sudheesh Katkam <[email protected]> > wrote: > > > Hey y'all, > > > > As part of https://issues.apache.org/jira/browse/DRILL-2304, I am trying > > to > > make the option name case insensitive. My question is: should option name > > be case-preserving during registration? Other components of Drill follow > > the 'case-preserving but case-insensitive' pattern. Jason and I don't > > think this component needs to follow that pattern. > > > > It looks like the current convention is to make option names lowercase. > If > > no one has objections, I will submit a new patch that ensures the option > > name is lowercase when registering, in addition to what the JIRA > requires. > > > > Thank you, > > Sudheesh > > >
