WebSurfer's Home

Filter by APML

MariaDB 10.11 をインストールしました

by WebSurfer 10. December 2024 13:33

MariaDB 10.11.10 を自分の PC (Windows 10 バージョン 22H2) にインストールしましたので、その手順などを備忘録として書いておきます。

2024 年 12 月に自分が使っているホスティングサービスで新サーバーへの移行がありました。新サーバーでは MariaDB 10.11 が使用されており、それに自分がブログアプリで使っているプロバイダ MySql.Data 6.3.6 でアクセスするとサーバーエラーになるという問題が生じました。

(MariaDB とMySql.Data との相性の話は MySQL Connector fails to connect to MariaDB 10.10.2 とか MySqlConnection.Open() System.InvalidCastException: Object cannot be cast from DBNull to other types に情報がありますので興味があれば見てください)

そういう訳で、自分の開発環境での検証用に、ホスティングサービスが使っている MariaDB 10.11 と同じバージョンのものを MariaDB Server: the innovative open source database から入手して自分の PC にインストールしました。(ちなみに、記事を書いた時点での最新版は 11.6.2 です)

まず、MariaDB のダウンロードページ Download MariaDB Server に行き、ドロップダウンリストでバージョンを選び[Download]ボタンをクリックします。

ドロップダウンリストで MariaDB Server 10.11.10 を選んだ場合 mariadb-10.11.10-winx64.msi という msi 形式のインストーラーがダウンロードされますので、それを起動してインストールします。

以下にインストールするときに表示された画像を貼って要点を書いておきます。

(1) 初期画面

初期画面

ダウンロードした mariadb-10.11.10-winx64.msi を起動すると上の画面が表示されます。[Next] ボタンをクリックします。

(2) Und-User License Agreement 画面

Und-User License Agreement

ライセンス条項が表示されるので、アクセプトして ([I accept the terms in the License Agreement] にチェックを入れて)、 [Next] ボタンをクリックします。

(3) Custom Setup 画面

Custom Setup

カスタム設定のための画面が表示されます。自分の環境ではデフォルトのままで問題ないので、何も変更せず [Next] ボタンをクリックしました。

(4) Deafult instance properties 画面 (1/2)

Deafult instance properties (1/2)

データベースに root ユーザーで接続する際のパスワードなどの設定画面が表示されます。今後の接続の際に使用するパスワードを決めて入力します。パスワードはおぼえておいてください。

[Use UTF8 as default server's character set] にチェックを入れます。[Data directory] はデフォルト C:\Program Files\MariaDB 10.11\data\ のままにしました。

ローカルでの検証用に使うだけなら [Enable access from remote machines for 'root' user] は不要ですが、将来そういう必要も出てくるかもしれないと思ってチェックを入れておきました。

以上の設定を入力して [Next] ボタンをクリックします。

(5) Default instance properties 画面 (2/2)

Deafult instance properties (2/2)

デフォルトの設定のまま [Next] をクリック・・・したのですが、"The TCP Port you selected is already in use. Please choose a differnt port." というエラーメッセージが出て先に進みません。

記録に残っていないですが、先に MySQL 8.0.19 をインストールした際、ポート 3306 を使用したようです。(ちなみに、ノート PC の MySQL 5.7.17 が 3306、PostgreSQL は 5432 というのは記録に残っていました)

という訳で、[TCP port] のみ 3307 に変更しました。その他は上の画面の通りのデフォルトのまま [Next] ボタンをクリックします。

(6) Ready to install MariaDB 10.11 (x64) 画面

Ready to install MariaDB 10.11 (x64)

[Install] ボタンをクリックします。ボタンには盾マークが表示されていますが、インストールの際に権限の昇格が必要という意味です。インストールが進まない場合はユーザーアカウント制御画面が表示されているはずなので [はい] をクリックしてください。

[はい] をクリックすると Installing MariaDB 10.11 (x64) 画面が表示され、インストールが開始されるはずです。

(7) Completed the MariaDB 10.11 (x64) Setup Wizard 画面

Completed the MariaDB 10.11 (x64) Setup Wizard

インストールが完了すると上の画面が表示されます。[Finish] ボタンをクリックして終了します。

(8) スタートメニュー

スタートメニュー

インストールの結果、Windows のスタートメニューには上の画像の項目が表示されます。

一番下の MySQL Client (MariaDB 10.11 (x64)) が MySQL の Command Line Client と同様なものらしいです。


メニューに含まれる HeidiSQL というのは、SQL Server Management Tool と同様に GUI で MariaDB の操作ができるツールのようです。詳しくは What is HeidiSQL? を見てください。

インストールした MariaDB に接続して使えるようにする方法を下に書いておきます。

(a) HeidiSQL 初期画面

HeidiSQL 初期画面

起動すると上の初期画面が表示されます。[新規] ボタンをクリックします。

(b) HeidiSQL 初期設定

HeidiSQL 初期設定

上の画面で名前を「ローカルMariaDB」とし (任意に覚えておきやすい名前を設定)、ポートを 3307 に変更 (ポートは MariaDB のインストール時に設定したもの)、パスワードに MariaDB のインストール時に設定したものを入力して [開く] ボタンをクリックします。

(c) HeidiSQL 画面

HeidiSQL 画面

上の画面が表示されます。「ローカルMariaDB」下に表示されている項目は、上の手順で MariaDB 10.11.10 をインストールした際に同時にインストールされたデータベースです。

自分は HeidiSQL を使って、データベース blogengine を作成し、[ファイル] ⇒ [SQL ファイルを実行] でホスティングサービスからエクスポートした SQL を走らせてブログの記事のデーターベースを複製しました。


上の手順でインストールした MariaDB 10.11.10 に MySql.Data を使って接続を試みるとどうなるかを検証してみました。

ちなみに、接続文字列は MySQL と同じものに port=3307 を追加すれば OK でした。以下の様にします。

server=localhost;user id=root;password=********;database=mysql;port=3307

MySql.Data 8.1 以降であれば、問題なく MariaDB 10.11.10 に接続でき、データを取得できました。

MySql.Data 8.0.11 では MySql.Data.MySqlClient.MySqlException "The host localhost does not support SSL connections." という例外がスローされます。

MySql.Data 6.x では System.InvalidCastException "オブジェクトを DBNull から他のタイプにキャストすることはできません。" という例外がスローされます。

・・・ということで、既存のブログアプリで使っている MySql.Data 6.3.6 がダメということでした。MySql.Data 8.1.0 は既存のブログアプリのフレームワーク .NET Framework 3.5 には対応してないので MySql.Data.dll を入れ替えれば済むという問題ではないことが分かりました。

Tags: ,

MySQL

Flask 開発サーバーが .mjs に Contents-Type: text/plain を返す

by WebSurfer 22. November 2024 13:48

開発マシンが Windows OS の場合、Flask 開発サーバーが拡張子 .mjs のファイルを応答として返す時、応答ヘッダの Content-Type が text/plain になるので (MacOS や Linux の場合は不明)、ブラウザは受信したスクリプトのロードに失敗することがありました。その理由と解決方法を備忘録として書きます。

元の話は Qiita の質問「アップロードしたファイルをPDF.jsビューワーで開きたい」で、PDF.js を Flask アプリで使うことに関する Q&A の際に自分が遭遇した問題です。

拡張子 .mjs のファイルはモジュール機能を持つ JavaScript ファイルです。<script> 要素に type="module" 属性を含めることでそのスクリプトがモジュールであることを宣言します。詳しくは MDN の記事「JavaScript モジュール」を見てください。

html コードに含まれる <script> 要素の src=".../xxx.mjs" 属性の指定による要求に応じて、Flask 開発サーバーが xxx.mjs ファイルを応答として返す時、応答ヘッダに含まれる Content-Type が text/plain になります。

その結果、下の画像のようにブラウザ (Chrome の例です) は受信した .mjs ファイルのスクリプトのロードに失敗します。

スクリプトのロードに失敗

上の画像のエラーメッセージに "Strict MIME type checking is enforced for module scripts per HTML spec." とあります。ブラウザは type="module" 属性を見て module scripts であると判定し、応答ヘッダに含まれる Content-Type が text/plain では HTML spec に反するのでロードしないと言っているようです。

ブラウザがスクリプトをロードできるようにするには、応答ヘッダの Content-Type を text/javascript にする必要があります。(application/javascript は RFC9239 で廃止になったそうで、text/javascript を使えということになっています。Windows OS のレジストリや IIS の MIME Mapping では未だに .js には application/javascript が使われていますが)

なぜ Flask 開発サーバーが Content-Type を text/plain に設定するかは、stackoverflow の記事 Python Flask - Error: "Failed to load module script. Strict MIME type checking is enforced". Works on production, not on the local server に書いてありますが、Windows PC の場合レジストリの設定情報を読んでくるからだそうです。

自分の環境の Windows 10 22H2 のレジストリを調べてみると、以下の通り .mjs は text/plain になってました。ということで、諸悪の根源は Windows OS ということのようです。

レジストリの設定

なお、レジストリに .mjs の設定がないケースがあって、その場合は mimetypes 内蔵のデータベースを使って拡張子から text/javascript と推測するので問題ないことがあるようです。

自分の開発マシンでは上の画像のとおりレジストリの設定があるのですが、レジストリをいじらなくても以下の様な設定で変更可能ということが上に紹介した stackoverflow の記事書いてありました。

import mimetypes
mimetypes.add_type('test/javascript', '.mjs')

試してみると、応答ヘッダの Content-Type は text/javascript になり、ブラウザはスクリプトをロードして期待通り動くようになりました。

PDF.js による表示

Tags: , , ,

その他

Blazor Web App の WebAssembly モード

by WebSurfer 17. November 2024 18:15

Visual Studio 2022 を使って下の画像のように Blazor Web App をテンプレートに選んで作成した Blazor アプリは、予想に反して WebAssembly モードでも Server-Side Rendering (SSR) になることがありました。以下にそのことを書きます。

Blazor Web App を選択

作成時に [Interactive render mode] を [WebAssembly] に設定しても、[Interactive location] に [Per page/component] を選んだ場合(多くの人はこちらを選ぶのではなかろうかと思います)、

[WebAssembly], [Per page/component] に設定

アプリを起動して [Home], [Counter], [Weather] ボタンをクリックして画面を切り替えると、

アプリを起動

下の Fiddler によるキャプチャ画像の通り、

Fiddler によるキャプチャ画像

毎回サーバーに要求を出し、完全な html ソースをサーバーから応答として受け取り、それをブラウザに表示するという SSR になります。WebAssembly だからサーバーとのやり取りはしない、即ち CSR になることを期待していましたがそうはなりません。

Microsoft のドキュメント ASP.NET Core Blazor render modes(日本語版もありますが翻訳がアレなので英語版がお勧め)の Render modes のセクションに説明があります。

そこにはコンポーネントで @rendermode を InteractiveWebAssembly に設定すると Client-side rendering (CSR) using Blazor WebAssembly となって Render location が Client になると書いてあります。

なので、試しに Home, Counter, Weather 全てのコンポーネントで @rendermode InteractiveWebAssembly を設定してみました。しかし、相変わらずサーバとのやり取りを行う SSR になります。

プロジェクトを作成する際に [Interactive location] を [Global] に設定すればサーバーとのやり取りはなくなり CSR になります。コンポーネントに @rendermode InteractiveWebAssembly を設定する必要はないようで、自動生成される各コンポーネントには @rendermode の設定は含まれていません。

知ってました? 自分は知らなかったです。 [Interactive render mode] を [WebAssembly] に設定するだけで無条件で CSR になると思ってました。WebAssembly のメリットは CSR のはずなので、勝手に知らないうちに SSR になっては困ると思うのですが・・・

ちなみに、テンプレートに Blazor WebAssembly を使って作成した Blazor アプリの場合は [Home], [Counter], [Weather] ボタンをクリックして画面を切り替えてもサーバーとの通信は発生せず CSR になります。


そのあたりのことを書いた Microsoft のドキュメントは見つからなかったので Copilot に聞いてみました。回答を載せておきます。(ホントかどうかの裏は取ってませんのでご参考まで)

(1) Blazor Web App と Blazor WebAssembly の違いに関して

The difference you're seeing between the two cases is indeed a bit subtle but has to do with how the Blazor Web App and Blazor WebAssembly templates are configured and what each is optimized for.

Blazor Web App

Interactive Render Mode: When you set the interactive render mode to WebAssembly but also have it set to Per page/component, Blazor is likely configured to request the server to render the pages/components interactively. This is why you're seeing GET requests being made to the server.

Behavior: Even though WebAssembly is being used, each time you navigate, a new GET request is made to the server. This means the server is still involved in delivering the HTML content, and the WebAssembly part is handling the interactive functionalities of the individual components on the page. This can be useful if you want the server to control the navigation and then WebAssembly to handle the client-side interactivity.

Blazor WebAssembly

Pure Client-Side Rendering: This template is optimized for a purely client-side experience. Once the initial application is loaded, all subsequent navigation and component rendering are handled entirely by the client without additional requests to the server.

Behavior: This makes it behave like a traditional Single Page Application (SPA) where the entire application, including navigation between pages, is handled within the client browser using WebAssembly. This is why you're not seeing additional requests to the server when navigating between Home, Counter, and Weather.

To summarize, the main difference is in how much the server is involved in rendering pages. In the Blazor Web App with interactive mode set to WebAssembly and per page/component, the server still plays a role in serving up pages, whereas, in Blazor WebAssembly, once the application is loaded, the server is not involved in further page rendering. This setup can affect performance and user experience depending on your application's needs.


(2) [Interactive location] を [Global] に設定すると何が変わるか

You're right, changing the Interactive location to Global in a Blazor Web App with the WebAssembly interactive render mode would make it behave similarly to the pure Blazor WebAssembly app, where no additional server requests are made during navigation. This setup alters the application's structure in a way that makes the WebAssembly component responsible for rendering more globally, not just per page/component.

Configuration Differences

Project Structure:

Global Interactive Location: This mode places components like Home.razor and Weather.razor under the .Client project, indicating that the client-side WebAssembly is handling the rendering globally for all these components.

Per Page/Component Interactive Location: In this mode, each page or component might still be interacting with the server for rendering purposes, leading to the behavior you observed with additional server requests.

Component Loading:

Global Interactive Location: The client-side WebAssembly loads the components globally, so once the application is loaded, navigation between different pages like Home, Counter, and Weather is handled entirely on the client side.

Per Page/Component Interactive Location: Each navigation may involve a server request because the rendering is done on a per-component basis, making the server more involved in the process.

Potential Reasons for Similar Program.cs

Shared Configuration: The Program.cs file might not differ significantly because the core configuration and service registrations for Blazor WebAssembly applications are quite similar. The main difference lies in how the application components are managed and rendered within the project structure and specific component files.

Conclusion

By setting the interactive location to Global, you've essentially optimized the application to function more like a typical SPA where the client-side WebAssembly handles most of the rendering and navigation logic, reducing the need for server interaction during page changes. This change primarily affects how components are structured and rendered rather than altering the fundamental configuration in Program.cs.

Tags: , , , ,

CORE

About this blog

2010年5月にこのブログを立ち上げました。主に ASP.NET Web アプリ関係の記事です。ブログ2はそれ以外の日々の出来事などのトピックスになっています。

Calendar

<<  February 2025  >>
MoTuWeThFrSaSu
272829303112
3456789
10111213141516
17181920212223
242526272812
3456789

View posts in large calendar