WebSurfer's Home

トップ > Blog 1   |   Login
Filter by APML

MySQL をインストールしました(その 3)

by WebSurfer 20. April 2020 10:16

先の記事「デスクトップ PC を買いました」の PC に MySQL 8.0.19 をインストールしました。8.0.19 はこの記事を書いた時点での最新版です。

MySQL 8.0.19

手順は「MySQL をインストールしました(その 2)」で書いた MySQL Community Server 5.7.17 のものとほぼ同じです。

前回 5.7.17 の時と同様に、今回も MySQL のダウンロードサイト MySQL Community Downloads からインストーラー mysql-installer-web-community-8.0.19.0.msi を入手し、上の画像の製品一式をインストールしました。

前回の手順と大きく異なる点のみ以下に備忘録として書いておきます。下の (7) とか (8) は先の記事「MySQL をインストールしました(その 2)」に書いたステップの番号です。

(7) タイプとネットワーク

ここまでは前回 5.7.17 の時とほぼ同じですが、この画面で[Next >]をクリックすると、前回は出なかった Authentication Method というダイアログが出ます。以下の画像を見てください。

Authentication Method

Use Legacy Authentication Method (Retain MySQL 5.x Compatibility) を選んで[Next >]をクリックします。

(9) MySQL サーバーへのアカウント登録

前回 5.7.17 の時は「(8) MySQL ユーザー詳細情報」がこのステップより先でしたが、今回はこちらが先になります。[MySQL Root Password]欄に任意のパスワードを入力し、[Add User] ボタンをクリックすると「(8) MySQL ユーザー詳細情報」のダイアログが出ます。設定したパスワードは忘れないように覚えておいてください。

(8) MySQL ユーザー詳細情報

この画面で User Name に root を設定すると既に使用されているというエラーになります。どうも root とは別のユーザーを設定するらしく、ここでは別の任意のユーザー名とパスワードを設定します。設定したユーザー名とパスワードは忘れないように覚えておいてください。

(ちなみに、前回の 5.7.17 の時はこの画面で User Name に root を設定、Password を入力して「(9) MySQL サーバーへのアカウント登録」に進むと、そこで[MySQL User Account]には (9) で設定したユーザー root が表示されました)

(13) 設定の完了

Apply Configuration

内容が前回と異なりますが気にせず続行します。

その後、MySQL Router Configuration というダイアログが出ますが、InnoDB cluster と関係あるものらしく、自分は利用しないのでチェックは入れずスキップして完了しました。


MySQL for Visual Studio の MySql.Data.dll 8.0.18 と Connector/NET の MySql.Data.dll 8.0.19 のバージョン不一致により Visual Studio の TableAdapter 構成ウィザードで不具合が出るという問題は依然としてあります。それについては別途記事を書く予定です。

Tags: ,

MySQL

VS2019 の Settings.settings 表示

by WebSurfer 19. April 2020 11:02

Visual Studio Community 2019 で Settings.settings ファイルを開くとデザイナ画面でなく xml コードが表示される問題とその解決方法を書きます。

Settings.settings

Visual Studio でアプリケーションの設定情報を保存するために使われる Settings.settings ファイルは、上の画像のように、ソリューションエクスプローラーで Settings,settings を右クリックし、表示されるダイアログで[開く(O)]を選択するとデザイン画面が表示されるのがデフォルトの設定でした(VS2008, VS2010, VS2015 はそうでした)。

ところが、つい最近気づいたのですが、Visual Studio Community 2019 v16.5.4(もっと前のバージョンからだったのかもしれません)ではデザイン画面ではなく生の xml 形式のコードが表示されてしまいます。

原因が分からず、心当たりもなく、ググって調べても同様の問題の記事はヒットしません。やむを得ず、Visual Studio Installer から修復を行っても解決しませんでした。(汗)

ググって調べた記事の中では Developer Community のスレッド VS 2019 Preview 2 Properties > Settings.settings editor is not opening だけが今回の問題に近かったので、もう一度よく読んでみると "Simple solution : Settings file to be Open With..."Settings Designer" as default" という書き込みがあります。

最初は意味が分からなかったのですが、英語版 Visual Studio では、上の画像の[ファイルを開くアプリケーションの選択(N)...]が "Open With..." になるということに気が付きました。

英語版の "Open With..." すなわち日本語版の[ファイルを開くアプリケーションの選択(N)...]で下の画像のダイアログが表示されます。

プログラムから開く

表示されるダイアログで[設定デザイナー]を選び[規定値として設定(D)]をクリックし、[OK]をクリックすると無事デザイナ画面が開きます。以降は[設定デザイナー]がデフォルトとなるので[開く(O)]でデザイン画面が開くようになります。

このような問題なら同じ事象を経験した人が多々いるはずで、ググればいくつか記事がヒットするのが普通だと思うのですが、上記の Developer Community の記事以外見つからなかったのは何故でしょう? 自分の環境特有のものだったのでしょうか?

Tags: , ,

DevelopmentTools

OData で ODataQueryOptions 使用

by WebSurfer 12. April 2020 17:11

Open Data Protocol (OData) を利用した ASP.NET Web API アプリで、ODataQueryOptions<TEntity> を引数に持つアクションメソッドを作る話を備忘録として書いておきます。

Open Data Protocol (OData)

OData を利用した ASP.NET Web API アプリの作り方は、.NET Framework ベースの場合は Microsoft のドキュメント Create an OData v4 Endpoint Using ASP.NET Web API に、Core ベースの場合は Experimenting with OData in ASP.NET Core 3.1 にあります。

(ちなみに、OData を利用するメリットですが、Creating an OData v4 API with ASP.NET Core 2.0 に書いてありますように、"the payload size and the querying of the data from the database" ということだそうです。確かにその通りだと思いました。OData に興味があれば読んでみることをお勧めします)

上に紹介した記事には書かれていませんが、Microsoft のドキュメント Invoking Query Options Directly によると、Advanced Scenarios(多分、より細かなコントロールが可能ということだと思います)として、ODataQueryOptions<TEntity> を引数に持つアクションメソッドを利用するオプションがあるそうです。

(注:記事に書いてある [Queryable] 属性は OData v3 の場合で、OData v4 または Core の場合は [EnableQuery] 属性になるようです)

ハマったのは、上の記事のコード results as IQueryable<Product> が null になってしまう場合があるということです。例えばこの記事では $select=name とした場合がそれです。

普通にアクションメソッドに [EnableQuery] 属性を付与する場合は以下のようにします。それだけで OData が有効になり、クエリ文字列に $select とか $top などを指定すればそれに従って JSON 文字列が返ってきます。

using System.Linq;
using Microsoft.AspNetCore.Mvc;
using ODataCore3API.DAL;
using ODataCore3API.Models;

using Microsoft.AspNet.OData;
using Microsoft.AspNet.OData.Query;

namespace ODataCore3API.Controllers
{
    [Produces("application/json")]
    public class ProductController : ODataController
    {
        private readonly ProductContext _context;

        public ProductController(ProductContext context)
        {
            _context = context;
        }

        [HttpGet]
        [EnableQuery]
        public IQueryable<Product> GetProduct()
        {
            return _context.Product.AsQueryable();
        }
    }
}

クエリ文字列を $select=name としても、期待通りの JSON 文字列が、この記事の上にある画像の通り返ってきます。アクションメソッドの戻り値を IQueryable<Product> としていますが、返ってくる JSON 文字列は IQueryable<Product> をデシリアライズしたものではないことに注目してください。OData がどこかでその違いを吸収しているようです。

[EnableQuery] 属性を削除して ODataQueryOptions<TEntity> を引数に持つアクションメソッドを使う場合、かつ $select=name でも対応できるようにするには以下のようにします。コメントに注目してください。

// ODataQueryOptions<Product> を引数に持つバージョン
[HttpGet]
public IActionResult GetProduct(
                ODataQueryOptions<Product> opts)
{
    IQueryable results = 
        opts.ApplyTo(_context.Product.AsQueryable());

    // 以下はダメ。$select=name としたとき null になる
    // return results as IQueryable<Product>;

    // アクションメソッドの戻り値を IActionResult とし
    // 以下のようにすれば $select=name でも OK
    return Ok(results);
}

上のコードは OData Query Options という記事を参考にしました。$select=name とした場合でも、この記事の上にある画像のとおり期待した JSON 文字列が返ってきます。

results as IQueryable<Product> が null になるのは考えてみれば当たり前だったのですが、そこに気が付かず半日ぐらいハマってしまった次第です。(笑)

Tags: , , ,

Web API

About this blog

2010年5月にこのブログを立ち上げました。その後 ブログ2 を追加し、ここは ASP.NET 関係のトピックス、ブログ2はそれ以外のトピックスに分けました。

Calendar

<<  June 2020  >>
MoTuWeThFrSaSu
25262728293031
1234567
891011121314
15161718192021
22232425262728
293012345

View posts in large calendar