Update Pomelo to v8.0.1

[bgrainger]

Fixes #2690

This reflects connection string validation changes from PomeloFoundation/Pomelo.EntityFrameworkCore.MySql#1819.

Microsoft Reviewers: Open in CodeFlow

[eerhardt]

Should we be setting these by default in the Aspire.Pomelo.EntityFrameworkCore.MySql package? Why force every user to do this?

[bgrainger]

This is only needed when you register a MySqlDataSource in DI (which is what these tests do). If you use Pomelo via a connection string (the default), it adjusts the connection string as necessary (which creates a new connection pool under the hood).

Most users should not need to do this.

[bgrainger]

I think Pomelo's integration with MySqlDataSource has some rough edges (that I ran into when building a WIP version of the AspireEFMySqlExtensions that used MySqlDataSource). I don't have a good suggestion for improving that, yet.

[eerhardt]

Just to confirm: because these tests use both Aspire.MySqlConnector and Aspire.Pomelo.EntityFrameworkCore.MySql this is required? So anyone who does the same would need to set these? (I agree it is not that common, just trying to make sure I understand.)

[bgrainger]

Specifically it's because these tests use builder.AddMySqlDataSource and AddMySqlDataContext, and these two extension methods don't play well together due to requirements in the underlying Pomelo provider.

I would like this interaction to be better, but not sure how common it would be in the real world.

[bgrainger]

because these tests use both Aspire.MySqlConnector and Aspire.Pomelo.EntityFrameworkCore.MySql this is required?

Since AddMySqlDataSource is the only Aspire.MySqlConnector extension method, and AddMySqlDataContext is the only Aspire.Pomelo.EntityFrameworkCore.MySql method, then your original statement was correct and my earlier response added nothing.

[bgrainger]

I started a WIP change to make Aspire.Pomelo.EntityFrameworkCore.MySql use a MySqlDataSource but ran into this exact problem. I think this is a point of friction that ideally would be addressed.

One thought I had is that UseAffectedRows=false, which is a connection-level setting, is the default. So most MySqlDataSource objects that a user creates would have the right value for that setting.

AllowUserVariables simply controls a runtime check for whether unmapped parameters have been used in the CommandText of a MySqlCommand. In theory, there's no reason why this check couldn't be suppressed on a command-by-command basis (while using the same underlying MySqlDataSource/connection pool). Pomelo could maybe tap into IDbCommandInterceptor to change this setting on a MySqlCommand (if support were implemented in MySqlConnector).