Fixes functions with parameters in Go

[rkodev]

Overview

Fixes generation fluent path in go for functions with paramerts e.g https://learn.microsoft.com/en-us/graph/api/reportroot-getyammeractivitycounts?view=graph-rest-1.0&tabs=http

Current behaviour

graphClient.Reports().GetYammerActivityCounts(period='{period}')().Get(context.Background(), nil)

expected behaviour

period = '{period}'
graphClient.Reports().GetYammerActivityCountsWithPeriod(&period).Get(context.Background(), nil)

Testing Instructions

• Unit tests

[andrueastman]

Any reason this is here and not using the FunctionWithParameterRegex in line 19?

[rkodev]

The need here was to extract the parameters used in the example

[rkodev]

I've combined these 2 since the existing regex both identify a function syntax. The difference is the new regex splits the function into "name" + "params" and make it simpler to return function names.

[andrueastman]

Multiple parameters is a possiblity that is not catered for.
Example at https://learn.microsoft.com/en-us/graph/api/callrecords-callrecord-getpstncalls?view=graph-rest-1.0&tabs=http

[andrueastman]

I think all you need to do here is call x.Segment.IsFunctionWithParameters()(already defined) then look up the parameters and values in snippetCodeGraph.PathParameters as

• Functions with multiple parameters could exists
• The snippetCodeGraph.PathParameters in contains type information that you can use to know for scenarios where the parameter is a number/Date type
• Casing is consistent with the metadata therefore generating names that are aligned with the generated SDK.

[rkodev]

Thanks for this. One concern with the Path Parameter is we can have an example using 1 or 2 params instead of all the path parameters. Thats the reason I opted for extracting the parameters from the snippet. I however do agree that the path param will give better type information

[andrueastman]

If a path had 3 parameters, and the example would use only 2 parameters, that would mean that one of the parameters is optional or has a pre-defined default. In such a case i believe the metadata would either

• have two distinct paths (one with the optional param and the other without).
• one path but the default would still need to be generated/passed as Kiota will still generate the parameter name in the function Handling of optional function parameters microsoft/kiota#2584

At this point of the snippet generation, the example path would already have been matched to the path that is relevant to it (when the snippet model is built) and every path parameter (including the optional ones if matched with their defaults) would be needed to be generated as only one url template is present and a parameter must be passed/included in function name.

Using the http URL would generate a function that does not exist in the SDK in such a scenario as the default parameter would be missing/not passed.

[rkodev]

The only left concern would be is it a given than the function with params is always the last segment of a path? This approach ensures that the params retain the position in the segment

[andrueastman]

It won't always be the last segment. But that is catered for as the operation can be checked on the specific segment as we traverse through the segments in the paths. Yes?
With the key values, you could still lookup casing/types from the snippetCodeGraph.PathParameters as well.

[andrueastman]

Latest updates break some tests in PHP/C#/Poweshell.

Any chance we can

• Fix the broken test.
• Add a test for Go for the test thats broken. Should point to the snippet at https://learn.microsoft.com/en-us/graph/api/callrecords-callrecord-getpstncalls?view=graph-rest-1.0&tabs=http

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
3 Code Smells

93.1% Coverage
0.0% Duplication