-
Notifications
You must be signed in to change notification settings - Fork 25
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
Default implementations in EntityServerService need to be removed #164
Comments
Thinking about it more - the implementation for |
In this case I feel they are justified for both backward compatibility and ease of transition. What we are assuming is that any user of the API fits into one of three categories for reconfigure
In the ExecutionStrategy case, what really needs to happen is the replication flag should be removed from the InvocationBuilder and this default implementation moved to default BOTH strategy. Again, we are trying to ease transition so replication flag stays for now and default implemention uses IGNORE. I understand that in most circles default implementations are considered a bad idea. In this case, the API is acting more like an SPI, almost part of the platform implementation. The developer that implements the API is likely the end user of that implementation. The interface defaults help smooth interactions at the API boundary. The default implementations also help us internally. It allows us to carve up commits in the implementations of the API so that we do not have to do a release at each method addition or squash commits implementing the addition of separate concepts. |
The implementation provided, while easing the transition into the API change, are really bad because they assume a number of things on the way the
Entity
works which cannot be generalised.It would be much better, especially at this beta stage of the API, to force users to implement them correctly for their own use case.
The text was updated successfully, but these errors were encountered: