Add undocumented taskLockType to MSQ.#15168
Conversation
LakshSingla
left a comment
There was a problem hiding this comment.
Added a few passing comments on the formatting of the error messages in accordance to https://github.com/apache/druid/blob/master/dev/style-conventions.md
| } else if (taskLockType.equals(TaskLockType.SHARED)) { | ||
| return SegmentTransactionalInsertAction.appendAction(segments, null, null); | ||
| } else { | ||
| throw DruidException.defensive("Invalid lock type %s received for append action", taskLockType); |
There was a problem hiding this comment.
nit: extrapolation
| throw DruidException.defensive("Invalid lock type %s received for append action", taskLockType); | |
| throw DruidException.defensive("Invalid lock type [%s] received for append action", taskLockType); |
| } else if (taskLockType.equals(TaskLockType.EXCLUSIVE)) { | ||
| return SegmentTransactionalInsertAction.overwriteAction(null, segmentsWithTombstones); | ||
| } else { | ||
| throw DruidException.defensive("Invalid lock type %s received for overwrite action", taskLockType); |
There was a problem hiding this comment.
| throw DruidException.defensive("Invalid lock type %s received for overwrite action", taskLockType); | |
| throw DruidException.defensive("Invalid lock type [%s] received for overwrite action", taskLockType); |
| throw DruidException.forPersona(DruidException.Persona.USER) | ||
| .ofCategory(DruidException.Category.INVALID_INPUT) | ||
| .build( | ||
| "TaskLock must be of type %s or %s for a replace query. Found type %s set." |
There was a problem hiding this comment.
- Capitalization of REPLACE to be consistent with error messages across MSQ
- Reworded the second sentence so that it makes sense without extrapolation as well - https://github.com/apache/druid/blob/master/dev/style-conventions.md?plain=1#L51
| "TaskLock must be of type %s or %s for a replace query. Found type %s set." | |
| "TaskLock must be of type %s or %s for a REPLACE query. Invalid lock type [%s] found." |
| throw DruidException.forPersona(DruidException.Persona.USER) | ||
| .ofCategory(DruidException.Category.INVALID_INPUT) | ||
| .build( | ||
| "TaskLock must be of type %s or %s for an insert query. Found type %s set." |
There was a problem hiding this comment.
| "TaskLock must be of type %s or %s for an insert query. Found type %s set." | |
| "TaskLock must be of type %s or %s for an INSERT query. Invalid lock type [%s] found." |
| for (TaskLockType taskLockType : new TaskLockType[]{TaskLockType.EXCLUSIVE, TaskLockType.REPLACE}) { | ||
| testLockTypes( | ||
| taskLockType, | ||
| "insert into foo1 select * from foo partitioned by day", |
There was a problem hiding this comment.
nit: Better capitalization in the test cases.
| "insert into foo1 select * from foo partitioned by day", | |
| "INSERT INTO foo1 SELECT * FROM foo PARTITIONED BY DAY", |
| .putAll(DEFAULT_MSQ_CONTEXT) | ||
| .put( | ||
| Tasks.TASK_LOCK_TYPE, | ||
| TaskLockType.REPLACE.name().toLowerCase(Locale.ENGLISH) |
There was a problem hiding this comment.
| TaskLockType.REPLACE.name().toLowerCase(Locale.ENGLISH) | |
| StringUtils.toLowerCase(TaskLockType.REPLACE.name()) |
| } else if (taskLockType.equals(TaskLockType.SHARED)) { | ||
| return SegmentTransactionalInsertAction.appendAction(segments, null, null); | ||
| } else { | ||
| throw DruidException.defensive("Invalid lock type %s received for append action", taskLockType); |
There was a problem hiding this comment.
Don't think we really need these exceptions (esp since the methods are private) here as we would reach these methods only after the validation is already done.
There was a problem hiding this comment.
I just like a more defensive approach here in case we break something above. I guess this check does not hurt functionality.
| if (isReplaceQuery) { | ||
| return TaskLockType.EXCLUSIVE; | ||
| } else { | ||
| return TaskLockType.APPEND; |
There was a problem hiding this comment.
Typo: I think this should be SHARED (as indicated in the javadoc of this method too)
kfaraz
left a comment
There was a problem hiding this comment.
Apart from minor comments and existing style feedback from @LakshSingla , the changes look good to me.
Thanks a lot for the quick fix, @cryptoe !
|
@LakshSingla @kfaraz I have addressed the comments. PTAL soon since this is a druid 28.0 work item. |
| segmentSortOrder, | ||
| replaceTimeChunks | ||
| ); | ||
| MultiStageQueryContext.validateAndGetTaskLockType(sqlQueryContext, |
There was a problem hiding this comment.
The return value is not being utilized. Is this call made to validate the lock type?
AmatyaAvadhanula
left a comment
There was a problem hiding this comment.
LGTM! Thank you @cryptoe
| * {@link TaskLockType#SHARED} is used for insert queries. | ||
| * If the queryContext contains the taskLockType, then it is validated and returned. | ||
| */ | ||
| public static TaskLockType validateAndGetTaskLockType(QueryContext queryContext, boolean isReplaceQuery) |
There was a problem hiding this comment.
In my mind, !isReplaceQuery means an INSERT or SELECT query. I see it's invoked only in the context of ingestion, but would also be good to clarify that in the javadoc since this class is common to all queries.
There was a problem hiding this comment.
@abhishekrb19 I will fix this as part of a upcoming PR. I kind of assumed TaskLocks means something to do with ingestion but yes I can be more clear there.
Patch adds an undocumented parameter taskLockType to MSQ so that we can start enabling this feature for users who are interested in testing the new lock types.
Patch adds an undocumented parameter taskLockType to MSQ so that we can start enabling this feature for users who are interested in testing the new lock types. Co-authored-by: Karan Kumar <[email protected]>
Patch adds an undocumented parameter taskLockType to MSQ so that we can start enabling this feature for users who are interested in testing the new lock types.
Patch adds an undocumented parameter taskLockType to MSQ so that we can start enabling this feature for users who are interested in testing the new lock types.
With #14258 going in, we want these lock types to be used by MSQ. This pr adds an undocumented parameter
taskLockTypeto MSQ so that we can start enabling this feature for users who are interested in testing the new lock types.This context parameter should be removed once these new lock types are battle tested.