Multiple stored procedures with the same name for different collections cause compilation error

[sspringer]

While attempting to connect to my document DB account, I received the following error:

Error: Exception - Cannot compile typed context: ; expected (line 1)

I simply:

• Pulled down the source code
• Created a new key (the one that the build was looking for was not in the solution)
• Rebuilt the driver, which deployed the drivers for me
• Renamed the Azure Document DB driver subfolder in LinqPad drivers folder (LinqPad complained if I didn't)
• Started LinqPad
• Attempted to set up my data source

Any thoughts? Have you seen this error before?

[conwid]

Thanks for trying out the component and bringing this issue to my attention.
I have to say, I'm not sure what the problem is; it seems like the generated code cannot be compiled, so there's probably some error in my code generation mechanism.

Can you maybe tell me more about your datasource? I will try to come up with a similar structure (I'm mostly interested in the number of collections, stored procedures and udfs).

[conwid]

As I have received no additional info for this and since have moved on to v2 with a new structure, I'm closing this. If the issue still exists with v2 and any additional info is provided, I'll take a look.

[jefflafay]

FWIW, I also have this issue. I tried the lpx package from the blog and also tried the v2.0 lpx in the link on the readme for the repo. Each one yields the same exception.

It states that 'LINQPad.User.TypedDataContext' already defines a member called 'count' with the same parameter types.

In case you need it, I'm using Linqpad v5.36.03 (pro edition).

[jefflafay]

So just glancing at the code, it appears that it happens in the SchemaBuilder.BuildAssembly() method. BTW, CompilerError objects also have a Filename property that you could use to log out more meaningful information. You might be able to figure out what's going on just based on the error but I'm not sure which DLL would be the offender.

[conwid]

Thanks for taking the time to look into this issue.

So basically what happens here is that in the BuildAssembly() I generate a class that represents your database. Every collection becomes a property and every sp becomes a method.

Any chance you have multiple SP-s with the same name (maybe count) in your database (even for different collections)?

[jefflafay]

Ah that makes sense! So yes it appears that there are two stored procs, each in a different collection, that are named "count".

[conwid]

OK, thanks. Obviously this should be handled - I will try to release a fix as soon as I can.

[conwid]

So I think I managed to fix and publish properly. Can you maybe help with the testing and provide some feedback? You can download v2.1.0.0 from the releases page.

[jefflafay]

I just got around to testing it and your changes work! One question though, will you be supporting setting a partition key in the future? It's crucial for me to use those with how our cosmos DBs are configured.

Thanks so much for your help with the bug!

[conwid]

Thanks for checking.
If you go ahead and open another issue about the partition key, I'm open to discuss why you need it and how it should work.