Github user paul-rogers commented on the issue:
https://github.com/apache/drill/pull/972
I think we have an opportunity here to take as step back and think a bit
about design rather than just applying code patches.
Drill must handle a large variety of names:
{noformat}
this.kind
this kind
$stranger+stuff#
{noformat}
Drill supports paths of names using Drill's SQL syntax:
*part1* . *part2* . *part3*
Drill's SQL rules require quoting if the name does not follow SQL naming
syntax or would be confused with a SQL reserved word (something we should fix):
{noformat}
fine.`needs.quote`.`also-needs+quotes`
{noformat}
So, we have three problems when dealing with external systems:
* How do we convert from the naming system of the external tool into Drill?
* How do we represent the names within Drill unambiguously?
* How do we give Drill's names back to the external system?
Drill must handle a variety of systems; Drill's internal naming system
can't bend with the wind to mean one thing for MySQL, another for Parquet and
something else for MapR DB. The conversion must be done at the interface.
Our convention is (or should be):
* External names, or at least those that are not valid Drill symbols, must
be quoted in SQL.
* Internally, each name segment is stored as a `NamePart` object, with a
collection of parts forming a `SchemaPath`.
* When calling back out to the external system, the interface (plugin) must
convert from Drill format back out to the external system format.
Now, let's consider this change. In Drill code, we call Drill methods to
convert Drill names to MapR DB format. While this just might work, it does not
really follow the above rules.
What we want is a `String drillToMapRDName(SchemaPath path)` method that
applies DB-specific rules for conversion at the point of calls into DB. All
names within Drill (unless cached only in the DB storage plugin) must be in
Drill's internal form.
This point would not be that important if Drill worked with just one
external system (DB in this case). But, as Drill evolves, it must work with a
variety of systems. We should not rely on methods on Drill classes to provide
the proper name format for external systems: external systems must provide
those rules. This is true even if it happens to work out, for now, that Drill's
current methods happen to work.
Just to drive the point home. Here we are changing a Drill method to
produce names in a format that DB needs. But, might some other external system
interface depend on the old format? How will this converge?
Bottom line:
Do the conversion in DB-specific code and will work fine.
---
