fix(mysql): route view DDL through text protocol

[danielnuld]

What

Routes MySQL create_view, alter_view and drop_view through sqlx::raw_sql() (the COM_QUERY text protocol) instead of sqlx::query().

Why

Saving a view from the view editor failed with:

1295 (HY000): This command is not supported in the prepared statement protocol yet

sqlx::query() uses MySQL's prepared-statement protocol (COM_STMT_PREPARE + COM_STMT_EXECUTE), and MySQL rejects CREATE VIEW / ALTER VIEW there with error 1295. The dedicated view-DDL functions are a separate code path from the editor's execute_query, so they never got the text-protocol treatment that transaction-control statements already have (is_text_protocol_stmt).

How

create_view / alter_view / drop_view now execute via sqlx::raw_sql(&query), mirroring the existing handling documented around is_text_protocol_stmt. No behavioral change for callers; the statements simply go over the text protocol that MySQL accepts for DDL.

Scope

Complementary to #348 (which routes routine DDL through the text protocol via the execute path); this fixes the dedicated view DDL functions called by the view editor's Save action. Postgres and SQLite are unaffected — error 1295 is specific to MySQL's prepared-statement protocol.

Testing

• cargo check --no-default-features passes.
• Reproduced the original 1295 against a local MySQL 8 by editing/saving a view; the statement succeeds via raw_sql.

[debba]

Nice fix — thanks for this! I pulled it down and went through it locally, and it holds up well.

I traced the Save path to make sure your reasoning checks out, and it does: the view editor goes commands.rs::{create,alter,drop}_view → the MySqlDriver trait impl → these free functions, and it never touches exec_on_mysql_conn/is_text_protocol_stmt. So you're right that the existing text-protocol handling just never reached this path — good catch. Pointing the comments at is_text_protocol_stmt is exactly the right breadcrumb, since that helper already does the same raw_sql dance for transaction/lock statements.

I also double-checked the "no behavioral change" claim: the old query(&query) was already passing a fully-formatted string with no bind params, so nothing's lost here — only the wire protocol changes. Postgres and SQLite are untouched, blast radius is just the MySQL Save path, and cargo test --lib drivers::mysql is green (21 passed). No new unit test, but I don't think one's warranted — it's a one-line executor swap and the actual behavior only shows up against a live MySQL.

One tiny thing, not a blocker: raw_sql over COM_QUERY can run multiple ;-separated statements, whereas the prepared path ran exactly one. The definition is user-controlled, but since they already have full SQL access through the query editor it's not a real injection/privilege concern — just flagging that the execution semantics shifted a hair.

LGTM, approving. 👍