-
Notifications
You must be signed in to change notification settings - Fork 205
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
Typed ACS and transaction streams for Java codegen #15159
Typed ACS and transaction streams for Java codegen #15159
Conversation
|
||
@Override | ||
public TransactionFilter transactionFilter(Set<String> parties) { | ||
Filter filter = new InclusiveFilter(Collections.emptySet(), Map.of(TEMPLATE_ID, Filter.Interface.INCLUDE_VIEW)); |
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.
Does it makes sense to always include view or maybe we should pass in a method argument here and let the caller decide
Filter.Interface.INCLUDE_VIEW
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.
If you don't include the view, the decoding part of the utility is guaranteed to fail to find the view. This utility should work in harmony with the other utilities that contribute to the goal of typed ACS/transaction streams.
import java.util.Optional; | ||
import java.util.Set; | ||
|
||
public final class ContractWithInterfaceView<Id, View> extends Contract<Id, View> { |
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.
An example of why I am reluctant to add extends
clauses to class or interface type parameters that aren't strictly necessary.
Sure, when defining Contract
, we could have made its second type parameter extends Template
. That would have compiled at the time. However, it has no functional benefits for the API, and then you would be stuck here.
While adding constraints to class tparams can be useful, it is more often no better than DatatypeContexts
aka "stupid theta" in Haskell, and just as worth avoiding.
...a/bindings/src/main/java/com/daml/ledger/javaapi/data/codegen/ContractWithInterfaceView.java
Outdated
Show resolved
Hide resolved
…ransaction-streams # Conflicts: # language-support/java/bindings/src/main/java/com/daml/ledger/javaapi/data/codegen/InterfaceCompanion.java
CHANGELOG_BEGIN CHANGELOG_END
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.
LGTM
language-support/java/bindings-rxjava/src/main/java/com/daml/ledger/rxjava/ContractUtil.java
Outdated
Show resolved
Hide resolved
...java/bindings-rxjava/src/main/java/com/daml/ledger/rxjava/grpc/ActiveContractClientImpl.java
Outdated
Show resolved
Hide resolved
...rt/java/bindings-rxjava/src/main/java/com/daml/ledger/rxjava/grpc/TransactionClientImpl.java
Outdated
Show resolved
Hide resolved
language-support/java/bindings/src/main/java/com/daml/ledger/javaapi/data/ActiveContracts.java
Outdated
Show resolved
Hide resolved
language-support/java/bindings/src/main/java/com/daml/ledger/javaapi/data/ActiveContracts.java
Outdated
Show resolved
Hide resolved
language-support/java/bindings/src/main/java/com/daml/ledger/javaapi/data/codegen/Contract.java
Show resolved
Hide resolved
...port/java/bindings/src/main/java/com/daml/ledger/javaapi/data/codegen/ContractCompanion.java
Outdated
Show resolved
Hide resolved
...ort/java/bindings/src/main/java/com/daml/ledger/javaapi/data/codegen/InterfaceCompanion.java
Outdated
Show resolved
Hide resolved
...ort/java/bindings/src/main/java/com/daml/ledger/javaapi/data/codegen/InterfaceCompanion.java
Outdated
Show resolved
Hide resolved
@chunlokling-da Additionally, I created #15191 to follow-up on this PR; if you want to think about what this PR would mean for that issue, I won't stop you 🙂 |
…ransaction-streams # Conflicts: # language-support/java/bindings/src/main/java/com/daml/ledger/javaapi/data/codegen/ContractCompanion.java # language-support/java/bindings/src/main/java/com/daml/ledger/javaapi/data/codegen/ContractTypeCompanion.java # language-support/java/bindings/src/main/java/com/daml/ledger/javaapi/data/codegen/InterfaceCompanion.java # language-support/java/codegen/src/main/scala/com/digitalasset/daml/lf/codegen/backend/java/inner/InterfaceClass.scala
.../java/bindings/src/main/java/com/daml/ledger/javaapi/data/codegen/ContractTypeCompanion.java
Outdated
Show resolved
Hide resolved
...egen/src/main/scala/com/digitalasset/daml/lf/codegen/backend/java/inner/InterfaceClass.scala
Outdated
Show resolved
Hide resolved
static <Ct> ContractUtil<Ct> of(ContractCompanion<Ct, ?, ?> companion) { | ||
Filter filter = new InclusiveFilter(Set.of(companion.TEMPLATE_ID), Collections.emptyMap()); | ||
return new ContractUtil<>(companion::fromCreatedEvent, filter); | ||
} | ||
|
||
static <Cid, View> ContractUtil<Contract<Cid, View>> of( |
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 suggest doing at least the ACS part of #15191 in this PR, if leaving aside the transaction stream part, as a sanity check for the API.
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.
Sure, it is now using the new ACS method in IouMain
language-support/java/bindings-rxjava/src/main/java/com/daml/ledger/rxjava/ContractUtil.java
Outdated
Show resolved
Hide resolved
… the new getActiveContracts. to address Stephen's comments
Per discussion out-of-band,
@chunlokling-da I believe there are symbol accessibility problems in this PR, but if you want to pick up #15191 right away to change the source/target in quickstart-java and update the example, then I think we can merge this one. |
@chunlokling-da The other bearing that #15191 has on this PR is: as we have discussed, the idea of the rxjava additions is a bit of a crucible to ensure the bindings library and codegen provide enough support to make implementing this kind of stream relatively easy to do. Likewise, the change to the quickstart-java is to ensure that the feature is powerful enough to support our tutorial and yields tutorial code that looks good; we can make further changes to this feature to ensure that both of those things are true in the PR for that issue. |
@NonNull | ||
public Optional<String> getOffset() { | ||
// Empty string indicates that the field is not present in the protobuf. | ||
return Optional.of(offset).filter(off -> !offset.equals("")); | ||
} | ||
|
||
@NonNull | ||
public List<@NonNull Ct> getContracts() { | ||
return activeContracts; | ||
} | ||
|
||
@NonNull | ||
public String getWorkflowId() { | ||
return workflowId; | ||
} |
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.
In general, we should define public final properties rather than private properties with getters.
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.
You can consider this for a follow-up PR though, e.g. the quickstart-java one.
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.
For the record, we do not care that Intellij thinks you shouldn't have Optional
fields.
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.
Sure will do it in the quickstart-java issue: #15191
fixes #14969