THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
Sqoop2 job information is persisted in the repository. We chose Derby as an initial implementation probably for its simplicity. Since we have a well-defined Repository API, it is possible to add support for additional DB implementation to store the Sqoop2 job and its associated information. The Sqoop2 entities such as the Connector Configurables, Links, Jobs, LinkConfigs and JobConfigs are currently modeled in a way that are best represented in a relational database, but it should be possible to store them in a document-store such as mongoDB and the constraints such as unique names across connectors might have to be modeled in code unlike in RDMS.
What are the main design goals of Sqoop2?The overarching goals are documented here. But there are more subtle ones will be added here.
From Gwen Shapira,
Remove the dependency between the connectors and the framework.The same way that an Oracle connector won't be able to assume a tnsnames.ora exists in the environment, we don't want Kite connector to assume that hive-site.xml will exist.The connector can still ask for a location of hive-site.xml as an input when creating a link though.
| Note |
|---|
Adding some fun facts about the design are encouraged! |