You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lens.apache.org by "Puneet Gupta (JIRA)" <ji...@apache.org> on 2015/10/07 11:24:26 UTC
[jira] [Comment Edited] (LENS-123) Ability to load different
instances of same driver class
[ https://issues.apache.org/jira/browse/LENS-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14946577#comment-14946577 ]
Puneet Gupta edited comment on LENS-123 at 10/7/15 9:23 AM:
------------------------------------------------------------
Approach-1**********************************************************
-Folders
--Driver
---driver1
----driver1-site.xml
---driver2
----driver2-site.xml
DriverFactory
scans Individual Driver folders and reads site.xml to get Driver class Name
Inits Driver via reflection
The Initialized driver reads <default-driver>-site.xml and <driver>-site.xml
Pros
- Plug and play
- Everything specific to a driver is contained in Driver's own directory
Cons
- <driver>-site.xml is read twice , once by factory to get driver class and once by driver itself
- if we have 5 jdbc drivers, We would be reading the same class name mapping 5 times (once from each driver site.xml)
Approach-2**********************************************************
Folders
-Driver
--hive
---driver1
----driver1-site.xml
---driver2
----driver2-site.xml
--jdbc
---driver1
----driver1-site.xml
DriverFactory
The lens-site.xml has a mapping for triver type and class Name (hive:org.apache.lens.driver.hive.HiveDriver,jdbc:org.apache.lens.driver.jdbc.JDBCDriver)
DriverFactroy initailizes drivers for each listed type.
Pros
- <driver>-site.xml will be read only once .
Cons
- Driver type and folder name should match
- Partially plug and play. New drivers form same type can be added without making any configuration changes. But a new driver type will have to be updated in lens-site.xml first .
Approach-3 **********************************************************
-Folders
--Driver
---driver1
----driver1-site.xml
---driver2
----driver2-site.xml
DriverFactory
reads driver-site.xml (a new configration which is in CONF directory along with lens-site.xml). All drivers need to be registered here first. Registeration can have driver_type,driver_folder(optional if path is diff from implied path),driver_class.
DriverFactroy initializes each registered driver.
Pros
- clean approach . No preconditions (like in approach 2 , driver type folder name should match registered driver type in lens-site.xml)
Cons
- Not plug and play. Have to update the driver-site.xml for each new driver
was (Author: puneet884):
Approach-1**********************************************************
Folders
Driver
driver1
driver1-site.xml
driver2
driver2-site.xml
DriverFactory
scans Individual Driver folders and reads site.xml to get Driver class Name
Inits Driver via reflection
The Initialized driver reads <default-driver>-site.xml and <driver>-site.xml
Pros
-Plug and play
-Everything specific to a driver is contained in Driver's own directory
Cons
- <driver>-site.xml is read twice , once by factory to get driver class and once by driver itself
- if we have 5 jdbc drivers, We would be reading the same class name mapping 5 times (once from each driver site.xml)
Approach-2**********************************************************
Folders
Driver
hive
driver1
driver1-site.xml
driver2
driver2-site.xml
jdbc
driver1
driver1-site.xml
DriverFactory
The lens-site.xml has a mapping for triver type and class Name (hive:org.apache.lens.driver.hive.HiveDriver,jdbc:org.apache.lens.driver.jdbc.JDBCDriver)
DriverFactroy initailizes drivers for each listed type.
Pros
-<driver>-site.xml will be read only once .
Cons
- Driver type and folder name should match
-Partially plug and play. New drivers form same type can be added without making any configuration changes. But a new driver type will have to be updated in lens-site.xml first .
Approach-3 **********************************************************
Folders
Driver
driver1
driver1-site.xml
driver2
driver2-site.xml
DriverFactory
reads driver-site.xml (a new configration which is in CONF directory along with lens-site.xml). All drivers need to be registered here first. Registeration can have driver_type,driver_folder(optional if path is diff from implied path),driver_class.
DriverFactroy initializes each registered driver.
Pros
clean approach . No preconditions (like in approach 2 , driver type folder name should match registered driver type in lens-site.xml)
Cons
Not plug and play. Have to update the driver-site.xml for each new driver
> Ability to load different instances of same driver class
> --------------------------------------------------------
>
> Key: LENS-123
> URL: https://issues.apache.org/jira/browse/LENS-123
> Project: Apache Lens
> Issue Type: New Feature
> Components: server
> Reporter: Amareshwari Sriramadasu
> Assignee: Puneet Gupta
> Labels: Hackathon-July
>
> Currently we are loading only one driver instance per class. We should be able to load multiple different instances of a driver class.
> For example, There can be multiple HiveDrivers talking to different HiveServers sitting on each colo. Or different JDBCDrivers talking to different dbs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)