search

palantir / atlasdb

Transactional Distributed Database Layer
https://palantir.github.io/atlasdb/
Apache License 2.0
53 stars 9 forks source link

JDBC (DBKVS) connectors should allow you to specify a schema #2066

Open gmaretic opened 7 years ago

gmaretic commented 7 years ago

C/P from ticket:

It would be great to be able to specify the schema that the tables are stored in when configuring a JDBC KVS. This will probably be necessary to achieve https://github.com/palantir/atlasdb/issues/2064 because if you log in as a different user, then all table names will need to be qualified by the schema that the normal AtlasDB connection uses.

Since JdbcKvs is not supported, we should implement this for Dbkvs instead

jboreiko commented 7 years ago

Not sure exactly what this request is... in the sense that a KVS is never aware of a schema regardless of how it is started. A atlas client that is instantiated without a schema will continue to behave correctly (with certain exceptions - https://github.com/palantir/atlasdb/issues/1532) by reading all relevant information from the metadata tables. This is how it is still able to correctly serialize / deserialize most objects (though not all).

GrahamDennis commented 7 years ago

@jboreiko: I'm talking about SQL schemas not Atlas Schemas. In SQL, a table is namespaced within a schema, e.g. schema_name.table_name. If you don't specify the schema name, then the table lives in the default schema for that user, which is often the user's name.

Currently Atlas does not explicitly specify an SQL schema when creating / accessing tables via DbKVS. I would like to be able to explicitly specify one in the config, so that #2064 will be possible. In #2064, I want to be able to start AtlasConsole with a separate, audited SQL account. As this account will have a different name, AtlasConsole would today try to access tables named my_user.table_name instead of atlas_user.table_name, and fail.

jboreiko commented 7 years ago

Okay, thanks for the clarification. Are you more interested in this being implement for Oracle or Postgres. I imagine the syntax will be different for the two / possibly require a bit of migration so it would be good if we could prioritize between the two.

Still a bit concerned about how to enforce that AtlasConsole uses a different audited user.

GrahamDennis commented 7 years ago

We care about Oracle more than Postgres, but it shouldn't matter as they use the same syntax. It's just an optional prefix to the tablename, i.e. instead of referring to the table by the name tableName, use schema.tableName.

There also shouldn't be a need for migration. If the schema name isn't provided in the config, you can keep referring to the table by the unqualified name tableName. If it is provided, then use schema.tableName.

I don't think we need to worry about enforcing that AtlasConsole uses a different audited user. In my ideal world, the default behaviour would be to prompt you for username/password and for convenience for deployments that don't want this, there would be a command-line option to use the creds from the config file.