generated from finos/software-project-blueprint
-
Notifications
You must be signed in to change notification settings - Fork 237
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
connman: wire up custom deserializer
- Loading branch information
Showing
29 changed files
with
508 additions
and
211 deletions.
There are no files selected for viewing
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,61 @@ | ||
# New Connection Framework (WIP) | ||
|
||
## Usage | ||
|
||
Set environment variable `org.finos.legend.engine.enableNewConnectionFramework=true` when running `Server.java` | ||
|
||
## Goals and Objectives | ||
|
||
This is _an attempt_ to create cleanup the existing connection acquisition framework to make it more extensible as well as make it integrate better with work that has been done on identity/credential management by @epsstan as well as feedback from @pierredebelen. The core mission centers around: **"How do we make it easy for people (both platform developers and users) to acquire database connection given their identity?"** | ||
|
||
Fundamentally, the new connection framework makes DX for integrating new type of connection easier and consistent across different types of databases (not limited to only relational databases); in other words, adding support for `MongoDB` or `ElasticSearch` should require similar set of change to adding support for `Snowflake` or `BigQuery`, for example. | ||
|
||
The new connection framework API is also designed to be more declarative about the flows that it supports, hence, it's a continuation of the work that has been done on `DatabaseAuthenticationFlow` by @epsstan. In the new framework, when we define the connection manager/factory, we make it very explicit which flows are supported, we have have broken the flows down nicely into 2 functional components: `CredentialBuilder` - (can be chained) taking the identity and build a credential, `ConnectionBuilder` - taking a credential and acquire a connection; therefore these pieces are reusable in many flows, and we make it feasible for the system to support chained flows use case. | ||
|
||
Last but not least, we want to clean up the existing connection pooling code using `HikariCP` which has become fairly complex after many iterations. | ||
|
||
## Metamodel | ||
|
||
![framework-metamodel](./new-connection-framework-metamodel.png) | ||
|
||
|
||
|
||
## Connection Pooling | ||
|
||
## Migration Strategy | ||
- For migration purpose, always assume to `credential vault` | ||
- [ ] Refactor further (breaking): | ||
- [ ] Move GCP Applicaton Defaults Credential to the right module | ||
|
||
## Further Work / TODO | ||
|
||
- [ ] Deal with all the hacks @HACKY | ||
|
||
- [ ] Allow enabling the custom deseiralizer via configuration flag | ||
- [ ] Add protocol and grammar for the adapter type for `DatasourSpecification` and `AuthenticationStrategy` | ||
- [ ] Add pure processing roundtrip? - or can we be lazy about this? | ||
- [ ] Change `ConnectionManagerSelector` to no longer have the adapter code, just scan for the type of `RelationalDatabaseConnection.ds and authStrategy`, and have a converter with for `DatabaseType`, using ServiceLoader | ||
- [ ] Annotate Usage | ||
- [ ] Annotate Hacky stuffs | ||
- [ ] Reshape the converter to respect the triplets so we can make it easier to convert flow by flow | ||
- [ ] write docs about this: | ||
|
||
- [ ] TODO: the reason we do lazy grammar/compiler/pure-metamodeling | ||
- [ ] Plan in the future: code-generation | ||
- [ ] Migration strategy, flow by flow | ||
- [ ] Pooling work | ||
|
||
- [ ] hikari is asynch | ||
- [ ] easy to acquire the connection, hard to re-establish the connection when it's lost (esp for secure connect), we cannot assume we have the identity outside of the pool, --> let's do lazy, when we lose the connection, we will re-create it in the context of the next call, because we cannot cache the identity <-- CONFIRM it's not reconnecting on loss | ||
- [ ] `Ephrim` - check if Hikari has the ability to create connection synchronously | ||
- [ ] Establishing connections is an expensive process | ||
- [ ] What we do is we maintain connection pools to different database, think of it like a hashmap with values are stateful connection objects | ||
- [ ] In some context, we want to do pushdown authentication, meaning, we cannot really share connection between people, An's connection to Snowflake_1 is different than Ephrim's connection to Snowflake_1, as such, the key of this hashmap is going to be made of the identity and the DB | ||
- [ ] There are many mishaps that could happen to the connection we store in the pool, the connection is destroyed, the DB restarts, the connection expires, etc. --> we need to be able to re-establish the connection, Pierre said it create a new connection from scratch, it's not easy when we thought we found a connection in the pool and the connection has already lost, because the connection creation process of our pool (Hikari) is asynchronous, it means, connection is created on a different thread than the thread of the request, which contains the user's identity & credential, so as part of us trying to re-establish the connection, we need to somehow send the user's information from the request thread to the connection making thread, but we absolutely must not CACHE the user credential/identity anywhere because that's bad --> so how do we do this? | ||
- [ ] 2 kerberos 1 thread | ||
- [ ] Refactor: | ||
- [ ] Create subtype of `Connection` | ||
- [ ] Realize the models into actual models, add Pure metamodel, etc. | ||
- [ ] Test out global deserializer | ||
- [x] `Q - EPHRIM` Discuss about vault shortId, why don't we just use `VAULT` stuff? instead???? Why should we differentiate different types? | ||
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
41 changes: 0 additions & 41 deletions
41
...src/main/java/org/finos/legend/connection/HACKY__RelationalDatabaseConnectionAdapter.java
This file was deleted.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
76 changes: 0 additions & 76 deletions
76
...ion/src/main/java/org/finos/legend/connection/impl/HACKY__SnowflakeConnectionAdapter.java
This file was deleted.
Oops, something went wrong.
Oops, something went wrong.