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.

Sign up for GitHub

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

Jump to bottom

[Programming Model] Function Format #2

Closed
asavaritayal opened this issue Aug 9, 2018 · 6 comments
Closed

[Programming Model] Function Format #2

asavaritayal opened this issue Aug 9, 2018 · 6 comments
Assignees
@joeyaiello
Labels
lang-PowerShell question Further information is requested

Comments

@asavaritayal
Copy link

asavaritayal commented Aug 9, 2018 •
edited
Loading

Summary

TBD (general information about the function format)

Binding to arguments

Input bindings

  1. Trigger input
    TBD

  2. Additional input
    TBD

Output bindings

  1. $return type
    TBD

  2. Generic type
    TBD

  3. Multiple output values for a single binding
    TBD

Referencing external modules

TBD

Logging

TBD

Async

TBD
@TylerLeonhardt TylerLeonhardt added the question Further information is requested label Sep 4, 2018
@asavaritayal
Copy link
Author

Noticed the label. Is there a question here? :)

@TylerLeonhardt
Copy link
Member

I saw it more of like... this is your question that you're asking. :) I kinda wish we filled this out but I think we have an answer for most if not all of it.

Here's what I have:

Summary

In general, we embrace PowerShell concepts. We use a param block for inputs and the ability to return things as outputs. For multi-output functions, we use a cmdlet called Push-OutputBinding.

Binding to arguments

Input bindings

  1. Trigger input
param($res)

or

param($res, $TriggerMetadata)

The user has access to the binding data via the param block of their function.

All trigger metadata will come in as $TriggerMetadata if they specify $TriggerMetadata in the param block. If they don't, then they won't have access to Trigger metadata.

  1. Additional input

Additional binding data will come in the param block:

param($res1, $res2)

Output bindings

  1. $return type
    The user is able to use the return powershell keyword or write directly to the pipeline. The last item in the pipeline will become the value that is stored in $return output binding.

  2. Generic type
    TBD

  3. Multiple output values for a single binding
    TBD

Referencing external modules

TBD

Logging

The user should be able to use the same Write-* cmdlets that they would do in a normal PowerShell script and those will get routed accordingly by log level.

Async

See #4

@TylerLeonhardt
Copy link
Member

@asavaritayal can you dig into what these are:

Generic type
TBD

Multiple output values for a single binding
TBD

@asavaritayal
Copy link
Author

Ah, got it!

By generic type, I meant a standard output type. You already answered that question.

For multiple output values for a single binding, I mean the scenario where we need to write multiple values to the same output binding. For e.g. if our function were to write 10 messages to the same queue, we shouldn't need to declare it 10 times in the function.json file. In C# we use a collector object for the same purpose and for python, we end up returning a tuple instead of a single value.

@TylerLeonhardt
Copy link
Member

TylerLeonhardt commented Sep 29, 2018 •
edited
Loading

we end up returning a tuple instead of a single value

So this is a bit confusing to me because tuples or arrays aren't valid grpc types (AFAIK). So does the worker look for this tuple and iterates over it and sends messages for each item with the valid grpc types (int, string, bytes, json, etc)?

@asavaritayal
Copy link
Author

I'm not certain about the implementation. @elprans can you please help out our PowerShell friends?

@joeyaiello joeyaiello modified the milestones: Unknown, Preview Nov 28, 2018
@joeyaiello joeyaiello mentioned this issue Dec 6, 2018
Closed
davidmrdavid added a commit that referenced this issue Apr 7, 2022
@davidmrdavid
# This is a combination of 37 commits.
3642ec0 
# This is the 1st commit message:

separate DF SDK classes from DF worker classes

# This is the commit message #2:

fix typo

# This is the commit message #3:

DurableSDK now compiles by itself

# This is the commit message #4:

Allow ExternalSDK to handle orchestration

# This is the commit message #5:

document next steps

# This is the commit message #6:

allow external SDK to set the user-code's input. Still need to refactor this logic for the worker to continue working with old SDK

# This is the commit message #7:

add import module

# This is the commit message #8:

supress traces

# This is the commit message #9:

avoid nullptr

# This is the commit message #10:

pass tests

# This is the commit message #11:

fix E2E tests

# This is the commit message #12:

develop E2E tests

# This is the commit message #13:

Enabled external durable client (#765)

Co-authored-by: Michael Peng <michaelpeng@microsoft.com>
# This is the commit message #14:

bindings work

# This is the commit message #15:

conditional binding intialization

# This is the commit message #16:

conditional import

# This is the commit message #17:

Added exception handling logic

# This is the commit message #18:

Revert durableController name to durableFunctionsUtils

# This is the commit message #19:

Ensure unit tests are functioning properly

# This is the commit message #20:

Corrected unit test names

# This is the commit message #21:

Turned repeated variables in unit tests into static members

# This is the commit message #22:

Fixed issue with building the worker

# This is the commit message #23:

Fix E2E test

# This is the commit message #24:

Fixed unit test setup

# This is the commit message #25:

Fixed another unit test setup

# This is the commit message #26:

Remove string representation of booleans

# This is the commit message #27:

patch e2e test
# This is the commit message #28:

remove typo in toString
# This is the commit message #29:

Update PowerShell language worker pipelines (#750)

* Install .Net to a global location

* Remove .Net installation tasks

* Update install .Net 6 task

* Update Windows image to use windows-latest
# This is the commit message #30:

Make throughput warning message visible for tooling diagnosis (#757)


# This is the commit message #31:

Update grpc.tools to version 2.43.0

# This is the commit message #32:

Update Google.Protobuf.Tools to version 3.19.4

# This is the commit message #33:

Revert "Update Google.Protobuf.Tools to version 3.19.4"

This reverts commit bcbd022.

# This is the commit message #34:

Revert "Update grpc.tools to version 2.43.0"

This reverts commit ccb323a.

# This is the commit message #35:

Update Google.Protobuf to 3.19.4 and grpc.tools to  2.43.0 (#762)

* Update grpc.tools to version 2.43.0

* Update Google.Protobuf.Tools to version 3.19.4
# This is the commit message #36:

Switch from Grpc.Core to Grpc.Net.Client (#758)

* Upgraded protobuf versions and removed Grpc.Core dependency

* Updated channel and option types used

* Change channel credentials

* Added http prefix to url

* Add valid URL check and explicitly include credentials
# This is the commit message #37:

Update pipeline logic to generate the SBOM for release builds (#767)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@joeyaiello joeyaiello

Labels
lang-PowerShell question Further information is requested
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@joeyaiello @TylerLeonhardt @asavaritayal