none
VS allows a Reducer to be placed in the code behind

    Question

  • I placed a custom Reducer in my USQL code-behind (not a separate assembly) and then created some USQL script to access it.

    Locally, it runs fine.

    If I submit it to Azure, it runs fine.

    However, if I wrap all the code in a stored procedure, submit it to Azure and then call the stored procedure, it fails.

    I then read that the code-behind should only have static methods and that I should move the Reducer code to a separate assembly. But then I'm wondering if any of the previous steps should have run successfully. Is this a bug? Shouldn't I be able to find out that I'm doing something wrong locally before pushing to Azure?

    Thanks!

    Saturday, July 16, 2016 9:34 PM

Answers

  • Code behind is handled specially in the IDE (automatically register / unregister a temporary assembly) when you submit or run the job and the special handling is limited to the main script only. That's why you need to register the assembly separately when you use stored procedure.    You can always test these locally (register to local DB) , the same as server run.

    Monday, July 18, 2016 7:47 AM
  • A stored procedure is a named code fragment that gets inlined into the script where it is being called/referenced.

    Since code-behind is changing your script by adding the assembly registration/reference and cleanup, that part is not present in the stored procedure invocation. Also, currently name resolution of user code objects inside TVFs and stored procs are only done against referenced assemblies inside the stored proc/TVF. So you cannot expect to see assemblies that are referenced outside them (which makes code-behind inaccessible from within a stored proc or TVF).

    So this means, that you have to register the assembly in the database and add the REFERENCE ASSEMBLY statement to your stored proc. This gives you self-containment and reusability across scripts.


    Michael Rys

    Tuesday, July 19, 2016 9:39 PM
    Moderator

All replies

  • Code behind is handled specially in the IDE (automatically register / unregister a temporary assembly) when you submit or run the job and the special handling is limited to the main script only. That's why you need to register the assembly separately when you use stored procedure.    You can always test these locally (register to local DB) , the same as server run.

    Monday, July 18, 2016 7:47 AM
  • A stored procedure is a named code fragment that gets inlined into the script where it is being called/referenced.

    Since code-behind is changing your script by adding the assembly registration/reference and cleanup, that part is not present in the stored procedure invocation. Also, currently name resolution of user code objects inside TVFs and stored procs are only done against referenced assemblies inside the stored proc/TVF. So you cannot expect to see assemblies that are referenced outside them (which makes code-behind inaccessible from within a stored proc or TVF).

    So this means, that you have to register the assembly in the database and add the REFERENCE ASSEMBLY statement to your stored proc. This gives you self-containment and reusability across scripts.


    Michael Rys

    Tuesday, July 19, 2016 9:39 PM
    Moderator
  • So what is the use case for code-behind then?
    Tuesday, July 19, 2016 10:55 PM
  • Code-behind is a way to develop scripts with custom-code where you manage your scripts as VS solutions and you feel that creating shareable assemblies are overkill.

    However, once you start to share code in U-SQL through the meta data service, any custom code inside that context needs to be shared via the meta data service as well so you have some consistency and global sharing.


    Michael Rys

    Wednesday, July 20, 2016 2:55 AM
    Moderator