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

ledger-api: Kill legacy identifier #2211

Merged
merged 3 commits into from
Jul 23, 2019
Merged

Conversation

remyhaemmerle-da
Copy link
Collaborator

@remyhaemmerle-da remyhaemmerle-da commented Jul 18, 2019

We drop support of (deprecated) legacy identifier in the ledger API.
This fixes #2208

Pull Request Checklist

NOTE: CI is not automatically run on non-members pull-requests for security
reasons. The reviewer will have to comment with /AzurePipelines run to
trigger the build.

Copy link
Contributor

@stefanobaghino-da stefanobaghino-da left a comment

Choose a reason for hiding this comment

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

Kill it with fire! 🔥

Copy link
Contributor

@gerolf-da gerolf-da left a comment

Choose a reason for hiding this comment

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

👍

@remyhaemmerle-da remyhaemmerle-da force-pushed the ledger-drop-deprecated-id branch 3 times, most recently from eee4617 to 7427e78 Compare July 18, 2019 12:59
@remyhaemmerle-da remyhaemmerle-da force-pushed the ledger-drop-deprecated-id branch 2 times, most recently from 610336f to b662cfa Compare July 18, 2019 14:08
@remyhaemmerle-da remyhaemmerle-da changed the title ledger-api: drop support for legacy identifier ledger-api: Kill legacy identifier Jul 18, 2019
@remyhaemmerle-da remyhaemmerle-da force-pushed the ledger-drop-deprecated-id branch from b662cfa to 653ff3b Compare July 18, 2019 14:16
* gRPC Identifier was built with the very old and ambiguous two-argument
* form. Use [[LegacyTemplateId]] instead if you want to extract
* the two-argument form.
/** Package ID, module name, and entity name.
*/
def unapply[Tpl](t: TemplateId[Tpl]): Option[(String, String, String)]
Copy link
Contributor

@S11001001 S11001001 Jul 18, 2019

Choose a reason for hiding this comment

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

Suggested change
def unapply[Tpl](t: TemplateId[Tpl]): Option[(String, String, String)]
def unapply[Tpl](t: TemplateId[Tpl]): Some[(String, String, String)]

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

fixed.

Copy link
Contributor

Choose a reason for hiding this comment

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

If you don't put Some here too it won't be visible.

// TODO SC DEL-6727 use this instead with daml-lf value interface
// rpcvalue.Identifier unapply t.unwrap
t.unwrap match {
case rpcvalue.Identifier(packageId, _, moduleName, entityName)
case rpcvalue.Identifier(packageId, moduleName, entityName)
if moduleName.nonEmpty && entityName.nonEmpty =>
Some((packageId, moduleName, entityName))
case _ => None
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
case _ => None

Copy link
Contributor

@stefanobaghino-da stefanobaghino-da Jul 19, 2019

Choose a reason for hiding this comment

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

I see the reasoning behind your suggestion but I'd suggest to keep the default case and throw a telling exception there: MatchErrors tend to be very vague and it would be easier to understand the issue if the exception had a meaningful message based on the context.

Copy link
Contributor

@S11001001 S11001001 Jul 19, 2019

Choose a reason for hiding this comment

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

There is no possibility of a MatchError in the set of changes I've suggested. That is to say, the prior case becomes exhaustive when you remove the condition.

Copy link
Contributor

Choose a reason for hiding this comment

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

Now there isn't, which is what makes the situation exceptional. In general, I hardly see good reasons to leave generic MatchErrors with very error messages leaving a lot to be said being possibly thrown at runtime when a more meaningful and contextualized. If there is not possibility that the match couldn't fail, wouldn't it be possible to simply do something like

val unwrapped = t.unwrap
Some((unwrapped.packageId, unwrapped.moduleName, unwrapped.entityName))

Seems more direct and readable.

Copy link
Contributor

Choose a reason for hiding this comment

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

Seems more direct and readable.

You are right but I can't express that in GH change suggestions :)

Copy link
Collaborator Author

@remyhaemmerle-da remyhaemmerle-da Jul 23, 2019

Choose a reason for hiding this comment

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

 val rpcvalue.Identifier(packageId, moduleName, entityName) = t.unwrap
 Some((packageId, moduleName, entityName))

Copy link
Contributor

@nickchapman-da nickchapman-da left a comment

Choose a reason for hiding this comment

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

The one line change to the haskell Convert,hs looks good to me.

@remyhaemmerle-da remyhaemmerle-da force-pushed the ledger-drop-deprecated-id branch from 653ff3b to 7a0d73f Compare July 23, 2019 07:42
case _ => None
}
override def unapply[Tpl](t: TemplateId[Tpl]): Some[(String, String, String)] = {
val rpcvalue.Identifier(packageId, moduleName, entityName) = t.unwrap
Copy link
Contributor

Choose a reason for hiding this comment

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

No we don't check anymore that moduleName and entityName are non-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.

For what I understand, the test was used to check if it is a new/old identifier.

Copy link
Contributor

Choose a reason for hiding this comment

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

Okay, but a templateId is only valid if the individual strings coming from the wire aren't empty. But maybe this is not the place to check this.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

The check is done inside the ledger API.
We probably do not need to duplicate the test in Scala binding side.

@remyhaemmerle-da remyhaemmerle-da force-pushed the ledger-drop-deprecated-id branch from 7a0d73f to 958fc45 Compare July 23, 2019 16:29
@cocreature cocreature force-pushed the ledger-drop-deprecated-id branch from 958fc45 to 2898f71 Compare July 23, 2019 20:06
@mergify mergify bot merged commit 53de5ed into master Jul 23, 2019
@mergify mergify bot deleted the ledger-drop-deprecated-id branch July 23, 2019 20:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component/ledger Sandbox and Ledger API
Projects
None yet
Development

Successfully merging this pull request may close these issues.

LegerApi: Drop support fro legacy Identifier
5 participants