[SPARK-6124] Support jdbc connection properties in OPTIONS part of the query#4859
[SPARK-6124] Support jdbc connection properties in OPTIONS part of the query#4859vlyubin wants to merge 1 commit into
Conversation
|
Can one of the admins verify this patch? |
|
Jenkins, add to whitelist |
|
Test build #28202 has started for PR 4859 at commit
|
|
Test build #28202 has finished for PR 4859 at commit
|
|
Test PASSed. |
There was a problem hiding this comment.
We should probably document this behavior somewhere -- I'm not sure if there's a standard place for data sources. If nowhere else, at least add it to the doc of createRelation().
There was a problem hiding this comment.
We should add this to the programming guide under JDBC.
There was a problem hiding this comment.
|
Test build #29012 has started for PR 4859 at commit
|
|
This LGTM, we'll merge this and later add a jdbc() version. |
|
Test build #29012 has finished for PR 4859 at commit
|
|
Test PASSed. |
There was a problem hiding this comment.
Why null as the default instead of an empty properties map?
There was a problem hiding this comment.
No particular reason really, both are fine with DriverManagers' getConnection(). I've switched to empty properties map, I guess it is in fact neater than null.
|
One minor comment otherwise LGTM, provided documentation and a programatic interface are added in a follow-up PR. |
|
Test build #29032 has started for PR 4859 at commit
|
|
Test build #29032 has finished for PR 4859 at commit
|
|
Test PASSed. |
|
Thanks! Merged to master and branch-1.3. |
…e query One more thing if this PR is considered to be OK - it might make sense to add extra .jdbc() API's that take Properties to SQLContext. Author: Volodymyr Lyubinets <vlyubin@gmail.com> Closes #4859 from vlyubin/jdbcProperties and squashes the following commits: 7a8cfda [Volodymyr Lyubinets] Support jdbc connection properties in OPTIONS part of the query (cherry picked from commit bfd3ee9) Signed-off-by: Michael Armbrust <michael@databricks.com>
One more thing if this PR is considered to be OK - it might make sense to add extra .jdbc() API's that take Properties to SQLContext.