Skip to content
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 basic workflow #3

Merged
merged 6 commits into from
Oct 8, 2023
Merged

Add basic workflow #3

merged 6 commits into from
Oct 8, 2023

Conversation

zklgame
Copy link
Collaborator

@zklgame zklgame commented Oct 7, 2023

No description provided.

request.startStateConfig(processOptions.getStartStateConfig().get());
}

public String startProcess(final ProcessExecutionStartRequest request) {
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use xdb public request as the input to BasicClient to reduce the SDK side wrapper.

@zklgame zklgame marked this pull request as ready for review October 7, 2023 16:35
@zklgame zklgame requested a review from longquanzheng October 7, 2023 16:35
return Strings.isNullOrEmpty(namespace) ? DEFAULT_NAMESPACE : namespace;
}

public String getType(final Class<? extends Process> processClass) {
Copy link
Contributor

@longquanzheng longquanzheng Oct 7, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It maybe better to move it to Process class as a package private method(, so that it doesn't require to pass in any parameter. ), or keep it in ProcessUtil

Passing a process class here is a bit strange

Copy link
Contributor

@longquanzheng longquanzheng Oct 7, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another idea: maybe it's even better to require passing in a Process instance when creating this ProcessOptions (is it possible in lombok to have a required field?, looks like by default all fields are optional in lombok --- looks like just put @NOT_NULL ?)

In the Process interface:

public interface Process{
 
   default getProcessOptions(){
         return ProcessOptions.build(this)
   }  
}

And we can make this build method as a helper to provide more parameters, like timeout, etc

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In lombok builder, the default value of each field is NULL. Adding @NonNull will make sure the specified field must be assigned with a non-null value at the RUNTIME.

Use ProcessOptionsBuilder builder(final Class<? extends Process> processClass) is a good idea to provide ProcessOptions.builder(this.getClass()).build().

Lombok also provides another way to genetate the ProcessOptionsBuilder by new ProcessOptions.ProcessOptionsBuilder(), I didn't find a way to disable it. So when using the new method to generate the builder, users have to be aware the processClass must be set explicitly.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So when using the new method to generate the builder, users have to be aware the processClass must be set explicitly.
yeah that's true. That's why it would be nice if the field being required is clear.
Though, usually when there is a helper build which is easier to use, users would not use the raw/harder one.


private final String id;

public String getId(final Class<? extends AsyncState> stateClass) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

similar here, it seems better to pass in the state instance as required for builder?


public class ProcessUtil {

public static final String DEFAULT_NAMESPACE = "default";
Copy link
Contributor

@longquanzheng longquanzheng Oct 7, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: I would feel slightly more natural if it's under ProcessOptions. Since it's a static field, it won't mess up with the lombok, I guess

return new AsyncStateExecuteResponse().stateDecision(toServerModel(request.getProcessType(), stateDecision));
}

private StateDecision toServerModel(final String processType, final io.xdb.core.state.StateDecision stateDecision) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: toApiModel or toInternalModels. the api is between server and SDKs, technically doesn't have to be owned by server

Copy link
Contributor

@longquanzheng longquanzheng left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

overall looks great, just some small comments

public static final Integer INPUT = 11;

@Override
public @NonNull StateSchema getStateSchema() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess @nonnull is not required right? It will look a little cleaner if it's not required

Copy link
Collaborator Author

@zklgame zklgame Oct 8, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nonnull will make sure the StateSchema will not be null at runtime. So that we don't need to check if (getStateSchema() == null) in case the user return null for the method. Adding it can reduce the checking logic on the SDK side.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like we don't have to enforce this. Our SDK can be smart enough to consider a null as empty schema.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it. Consider a null as empty schema sounds like a more user-friendly approach. I will remove the nonnull annotation and deal with the null cases.

System.out.println("BasicStartingState.waitUntil: " + input);
Assertions.assertEquals(INPUT, input);

return new CommandRequest().waitingType(CommandWaitingType.EMPTYCOMMAND);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: it would be better if it provide a helper:

CommandRequest.empty();

or 

CommandRequest.empty;

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True, when we are ready for other CommandWaitingTypes, we should add helper like StateDecision. I will add it that time.

Copy link
Contributor

@longquanzheng longquanzheng Oct 8, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah no problem. You may want it when start writing samples or more integ tests because it will save time. We can always change it later before final launch. When it’s time to share with more people we will have another review to refine the APIs

Assertions.assertEquals(INPUT, input);

return StateDecision.multipleNextStates(
StateMovement.builder().stateId(STATE_ID_NEXT_1).stateInput(input + 1).build(),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

similar here, it would be nicer to have a helper:

Statemovement.create(stateId [class/string], input);

@zklgame zklgame merged commit fa421f3 into main Oct 8, 2023
1 check passed
@zklgame zklgame deleted the add_basic_workflow branch October 8, 2023 05:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants