-
Notifications
You must be signed in to change notification settings - Fork 77
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for Oracle as backend database #89
Conversation
return QueryHistory.upcast(QueryHistory.findBySQL(String.join(" ", | ||
sql, | ||
"order by created desc", | ||
"limit 2000"))); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I removed this hard-coded SQL since LIMIT
is not supported in Oracle.
@@ -77,7 +77,6 @@ public static List<ResourceGroupsDetail> upcast(List<ResourceGroups> resourceGro | |||
* @param resourceGroupDetail | |||
*/ | |||
public static void create(ResourceGroups model, ResourceGroupsDetail resourceGroupDetail) { | |||
model.set(resourceGroupId, resourceGroupDetail.getResourceGroupId()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I made this change to ensure auto-increment resource group ID column is used.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a few minor comments, thanks for the submission!
if (user.isPresent()) { | ||
sql += " where user_name = '" + user.get() + "'"; | ||
return QueryHistory.upcast(QueryHistory.where("user_name = '" + user.get() + "'").limit(2000).orderBy("created desc")); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
use QueryHistory.userName
instead of "user_name"
and QueryHistory.created
instead of "created"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It appears all the attributes of the activejdbc models are private. Should we add getters for them? Not sure what the typical activejdbc pattern is for this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should make these public IMO
CREATE INDEX query_history_created_idx ON query_history(created); | ||
|
||
CREATE TABLE resource_groups ( | ||
resource_group_id NUMBER GENERATED ALWAYS as IDENTITY(START with 1 INCREMENT by 1), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know Oracle very well, but would a LONG
be a better choice than a NUMBER
? Iiuc a NUMBER
with unspecified scale supports real numbers as well as integers. Not that it probably matters much
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
a LONG
in oracle is not actually a numeric data type confusingly enough :) https://docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/Data-Types.html#GUID-F6309DF8-162F-48A4-9454-FEE59EC6644F
I would vote to use NUMBER
as the data type for the identity column here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After reviewing, I'd agree
@@ -18,7 +18,7 @@ CREATE INDEX query_history_created_idx ON query_history(created); | |||
|
|||
CREATE TABLE IF NOT EXISTS resource_groups ( | |||
resource_group_id BIGINT NOT NULL AUTO_INCREMENT, | |||
name VARCHAR(250) NOT NULL UNIQUE, | |||
name VARCHAR(250) NOT NULL, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are we changing the MySQL sql for this PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I updated it to match the schema in trino for consistency - https://github.com/trinodb/trino/blob/master/plugin/trino-resource-group-managers/src/main/resources/db/migration/mysql/V2__add_resource_groups.sql
Happy to revert if unique names need to be enforced for gateway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One use case for non-unique names I have had in the past with Trino is storing the same resource group definitions for different environments in the same database. This is possible since resource groups are determined by the environment
column of the resource_groups
table. So you could use a single database and have the same resource group definitions for multiple environments.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure. Trino clusters require an environment name set, while the gateway could front backends with different environment names. So environment could be less meaningful in the gateway context. OTOH, this is defined by the user, and they can choose not to complicate things.
I guess being able to import a set of policies from Trino to the gateway probably wins out.
Also, a general comment here - we are supporting almost 3 dbs now, will it be a good idea to use migrations now than actual DDL like Flyway. |
Totally agree .. that could also help with installation/ bootstrap .. and we need to figure out testing for the different backends. |
We are using flyway in trino for resource group migrations so could likely reuse some of what we did there. Are we good with doing this in a follow up PR though? |
219b650
to
6469a13
Compare
|
0ce3613
to
8595d29
Compare
@willmostly @mosabua OK I rebased against latest master to resolve conflicts. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks ready to go. @posulliv and I have discussed offline and will begin work to introduce Flyway for schema management once this PR is merged
At minimum a rebase has to be done. I can review more then .. |
|
||
```$xslt | ||
curl -X POST http://localhost:8080/trino/selector/create \ | ||
-d '{ | ||
"resourceGroupId": 1, \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that seems like a bad idea .. how would you know what number to use? An id should be created automatically. Also .. this change should be independent and separate
gateway-ha/src/main/java/io/trino/gateway/ha/persistence/dao/QueryHistory.java
Outdated
Show resolved
Hide resolved
8595d29
to
1b600dd
Compare
1b600dd
to
8119bd0
Compare
Rebased but tests failing now. Will try to figure it out when I get a chance this week. |
@ebyhr the problem I'm facing now is that the SQL in Any suggestions on the preferred approach to deal with this in JDBI? |
@posulliv We can call different dao methods based on the connection-url prefix |
Chatted with @willmostly .. I think this can be closed and restarted when it becomes relevant. Feel free to reopen after rebasing and adjusting |
No description provided.