gjacoby126 commented on a change in pull request #457: PHOENIX-5190 Implement
TaskRegionObserver for Index rebuild
URL: https://github.com/apache/phoenix/pull/457#discussion_r265716197
##########
File path:
phoenix-core/src/main/java/org/apache/phoenix/coprocessor/TaskRegionObserver.java
##########
@@ -157,18 +191,58 @@ public static void addTask(PhoenixConnection conn,
TaskType taskType, String ten
PhoenixDatabaseMetaData.TENANT_ID + ", " +
PhoenixDatabaseMetaData.TABLE_SCHEM + ", " +
PhoenixDatabaseMetaData.TABLE_NAME + " ) VALUES(?,?,?,?)");
- stmt.setByte(1, taskType.getSerializedValue());
- if (tenantId != null) {
- stmt.setString(2, tenantId);
+ stmt = setValuesToAddTaskPS(stmt, taskType, tenantId, schemaName,
tableName);
+ } catch (SQLException e) {
+ throw new IOException(e);
+ }
+ mutateSystemTaskTable(conn, stmt, accessCheckEnabled);
+ }
+
+ public static void addTask(PhoenixConnection conn, TaskType taskType,
String tenantId, String schemaName,
Review comment:
Seems like there should be a separation of concerns here -- persisting a
Task to a Phoenix table and reading it back is distinct from scheduling a task.
I'd suggest breaking some of these Task classes into their own files and either
fully encapsulate their persistence logic in the Tasks (the Data Access Object
pattern) or have standalone persistence classes that handle the persistence
(the Repository pattern).
Either way would improve the readability and reduce the coupling between the
scheduling logic and the persistence logic.
Also agree with @kadirozde 's ideas to use reflection and JSON parsing to
reduce the amount of boilerplate necessary to hook in each new task type for
this framework.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
With regards,
Apache Git Services
