RENAMED: Additional spacing breaks ProviderName support in connectionString

[ericwonglc]

Hi Mike,

I am trying out your Mighty ORM in .net core environment.

My code:
string connectionString = "data source = localhost; initial catalog = LegalBO; User Id = sa; Password = abc; persist security info = False; packet size = 4096; ProviderName=System.Data.SqlClient;";

    MightyOrm groups = new MightyOrm(connectionString, "S53Groups", "RecPk");
    dynamic group = await groups.Single(1);

I receive this error code:

   InvalidOperationException: Cannot find ProviderName=... in connection string passed to MightyOrm

Could you please help me to get it right? Thank you very much.

Best regards,
Eric Wong

[mikebeaton]

Can you try without all the additional extra spacing in your connection string, i.e.:

string connectionString = "data source=localhost;initial catalog=LegalBO;User Id=sa;Password=abc;persist security info=False;packet size=4096;ProviderName=System.Data.SqlClient;"

I think that should get you working.

I haven't seen a connection string done like that, with all that spacing in, before, but if the rest of it works for you normally, spaced like that, then you're correct that Mighty should support ProviderName spaced the same way, so that needs fixing.

[mikebeaton]

PS In the next full version of Mighty I'm going to support optionally passing in provider name in a separate parameter, but that isn't available yet.

[ericwonglc]

Dear Mike, Thank you for your quick response. Before receiving your email, I managed to get it working by placing the ProviderName segment at the beginning. Strange to me, but it works that way. Thanks anyway. By the way, Mike, May I ask "Will you commit to maintain Mighty for some time to come?". I am considering using Mighty in my next project, which hopefully shall run in the next 5-10 years. I am worrying if Mighty would be a short-life library. I come from the Javascript world and have used and liked Massive.JS so much. I really hope to have a similar library in the .net Core world. Best regards, Eric

…

On Tue, 29 Sep 2020 at 17:52, Mike Beaton ***@***.***> wrote: Can you try without all the additional extra spacing in your connection string, i.e.: string connectionString = "data source=localhost;initial catalog=LegalBO;User Id=sa;Password=abc;persist security info=False;packet size=4096;ProviderName=System.Data.SqlClient;" I think that should get you working. I haven't seen a connection string done like that, with all that spacing in, before, but if the rest of it works for you normally, spaced like that, then you're correct that Mighty should support ProviderName spaced the same way, so that needs fixing. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#33 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGIUCAMIEBZRFUVQZXEMJZTSIGU4TANCNFSM4R5MJIZQ> .

[mikebeaton]

I'm glad you've got it going already! I would imagine that's working because by putting it first you don't have a space before the word ProviderName, which I'm still guessing is what is breaking it.

I'll look into this, and leave this open as a bug for now.

That nobody's reported this before I think must be because most people just use tightly spaced connection strings, which is all I've ever seen in examples, etc.! But I'll double-check, and assuming the more loosely spaced version works on the underlying providers then yes, of course, Mighty should also work with it. (And even if not, the error message you got isn't as helpful as it could be, given what you passed.)

Finally, as with any open source project, I can't give you any guarantee. I do this voluntarily, and there's only one of me (as was the case with Rob Conery and then Frans Bouma on Massive, on which Mighty is fundamentally based). But yes, my current plan is to continue to maintain and support this project for at least the next several years. It took quite a bit of work to get it to this stage, and I'd like to see it used!

[ericwonglc]

I have tried to remove those additional spaces as you suggested. It works. Thank you for your information about your current plan. One last question, do you think I am safe to use Mighty for my project (i.e. is Mighty production ready)? Best regards, Eric

…

On Tue, 29 Sep 2020 at 18:46, Mike Beaton ***@***.***> wrote: I would imagine that's working because by putting it first you don't have a space before the word ProviderName, which I'm still guessing is what was breaking it. I'll look into this, and leave this open as a bug for now. That nobody's reported this before I think must be because most people just use tightly spaced connection strings, which is all I've ever seen in examples, etc.! But I'll double-check, and assuming the more loosely spaced version works on the underlying providers then yes, of course, Mighty should also work with it. (And even if not, the error message you got isn't as helpful as it could be, given what you passed.) Finally, as with any open source project, I can't give you any guarantee. I do this voluntarily, and there's only one of me (as was the case before, of course, with Rob Conery and then Frans Bouma on Massive, on which Mighty is based). But yes, my current plan is to continue to maintain and support this project for at least the next several years. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#33 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGIUCAJLGAEMZVAOKKPKE53SIG3KBANCNFSM4R5MJIZQ> .

[mikebeaton]

I'm using it in production myself, it has a comprehensive test suite (inherited from and extended from the one in Massive) to ensure that continuing upgrades don't change or break anything, and I'm planning to support it. It's also pretty fast. So yes, I consider it production ready.

If I was to mention one thing then, as far as I know, Mighty hasn't been load tested on a massively high throughput site (I mean 10,000s or upwards of requests per second). If you were planning to use it for that, you should probably be writing your own load tests anyway (and feel free to submit any results or code back to the project!). I'm genuinely not aware of any specific issues here, just giving you fair warning that if I was to mention one thing that I don't know that it does okay, it's that.

In the end, however, you need to bear in mind the license, and make your own assessment based on the history, functionality, usage, support, repository activity, etc. of the project - and compare this to any other free or non-free, open or non-open alternatives you might be considering - as you should with any free, open source software!

[ericwonglc]

Thank you for your Detailed information. And yes, I will do some more evaluation before committing. Nice Talking to you and you are very helpful. Best regards, Eric

…

On Tue, 29 Sep 2020 at 7:21 PM, Mike Beaton ***@***.***> wrote: I'm using it in production myself, it has a comprehensive test suite (inherited from and extended from the one in Massive) to ensure that continuing upgrades don't change or break anything, and I'm planning to support it. It's also reasonably fast <https://github.com/StackExchange/Dapper#performance>. So yes, I consider it production ready. If I was to mention one thing then, as far as I know, Mighty hasn't been load tested on a massively high throughput site (I mean 10,000s or upwards of requests per second). If you were planning to use it for that, you should probably be writing your own load tests anyway (and feel free to submit any results or code back to the project!). I'm genuinely not aware of any specific issues here, just giving you fair warning that if I was to mention one thing that I don't *know* that it does okay, it's that. In the end, however, *you* need to bear in mind the license <https://github.com/MightyOrm/Mighty/blob/master/LICENSE>, and make your own assessment based on the history, functionality, usage, support, repository activity, etc. of the project - and compare this to any other free or non-free, open or non-open alternatives you might be considering - as you should with any free, open source software! — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#33 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGIUCALRY5356K6OTKYHAU3SIG7MNANCNFSM4R5MJIZQ> .

[mikebeaton]

@ericwonglc I double-checked and you are completely right that all Mighty's supported providers accept connection strings spaced out as you were doing it - so Mighty should definitely have accepted what you originally provided.

I've just updated it with a fix, so you can space your connection string in any standard way you prefer now. 😎

https://www.nuget.org/packages/Mighty/3.1.3

Thanks for flagging that up.

[ericwonglc]

Dear Mike, Thank you very much for your fix. You are wonderful. Best regards, Eric

…

On Mon, 5 Oct 2020 at 19:15, Mike Beaton ***@***.***> wrote: @ericwonglc <https://github.com/ericwonglc> I double-checked and you are completely right that all Mighty's supported providers accept connection strings spaced out as you were doing it - so Mighty should definitely have accepted what you originally provided. I've just updated it with a fix, so you can space your connection string in any standard way you prefer now. 😎 https://www.nuget.org/packages/Mighty/3.1.3 Thanks for flagging that up. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#33 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGIUCAPH4FW2ZTOWZ3WMQNLSJGTEHANCNFSM4R5MJIZQ> .