QST：QsT SQLツール、Qtツールキット

UPD

このブログはadvixのおかげで登場しました。 この人はサンドボックスへの投稿を招待しました。彼に心から感謝しています。



こんにちは、愛するhabrasociety！

データベースアプリケーションのプログラミングを簡素化するために書かれたQtの小さなライブラリを裁判所に紹介したいと思います。 それを使用して、注文するデータベースを1つ作成しました。これは単なる用語集ですが、多くの点を磨き、考えるのに役立ちました。 今、私は真面目な組織のために、すでに現実の別のデータベースを書いています。 ライブラリに新しい機能を少しずつ追加します。 いつか良いことが判明するでしょう。

前文

2009年の夏以来、私はQtを積極的に研究しています。 そして、あなたはこの環境でプログラムすることを本当に嬉しく思います。 彼女は私のすべての主な問題を解決しました。 たとえば、プログラムインターフェイスの構築方法がわからなかったため、同じBuilderのすべてのコントロールを整列、ドラッグ、サイズと位置を調整する必要があることは特に面倒でした。 Qtを使用すると、そのことを忘れることができます。そして、ルーチンなしで美学に専念できます。 さらに、私はSTLがその巧妙なアプローチで気に入っており（まだまだ知りませんが）、Qtには独自のコンテナがあるだけでなく、喜んで使用しています。 また、「キット」-非常に考え抜かれたライブラリ、すべてのそのようなOOP-shnayaと技術。 そして、私はOOPとデザインパターンを本当に尊重し、尊重しています...

夏の終わりに、データベースの注文を受け取ります。 何を書くべきかという質問は価値がありません。 もちろん、Qt！ 練習は、まだ隠されているものを学ぶのに役立ちます。 アプリケーションの作業を開始しています。 美しいフォームが得られ、コードを書くのが便利で、すべてが揃っているようです...そして、私は幸せになるはずですが、ここではSQL-C ++コードから麺を入手します。 間違いなく危険な、困難なものを伴う、一見不満のように見える人...どうして人々は目を見て、自分をプログラマーと呼ぶことができますか？

したがって、デザイナーが生まれました。 はい、すべてのこの不名誉を取り除くために設計された小さなプロジェクト。 幸いなことに、その道は打ちのめされており、すべてのプログラミング言語、すべてのプラットフォームについて、すでにそのようなことがあります。 まあ、大丈夫です。 私は自分自身が欲しいです。特にQtのもとでは、賢明なものは見つかりませんでした。

QST：QsT SQLツール

これはツールキットであり、むしろライブラリであり、さらに良いことに、コードの「SQLヌードル」からプログラマを救うクラスのセットです。 当然、クエリ生成を使用しますが、単純ではありませんが、特別なDFD記述子を使用します。これにより、多くの便利な利点が得られます。 どういうわけか、データベーステーブルのフィールドを名前で見て、データを抽出し、リクエストごとに異なるDFD記述子を使用し、ビューモデルを操作し、これをすべてハンドラクラスにカプセル化しますが、それでも多くのことができます。 ...

しかし-順番に。

Dfd

私はDFDという概念を開発しました： 「宣言型フィールド記述子」 。 （L [anguage]を追加したいのですが、言語に描画されますか？..）記述子から単純なSQLクエリを生成する概念。 例で説明するのが最も簡単です。 次に、このようなリクエストを作成します。



SELECT [ID], LastName, FirstName, ParentName, SerialNumber, Number, DocType_ID

FROM tPersonalDocuments

WHERE

[ID] > 30

AND

DocType = 1









そして、次のようになります。



SqlBatch batch;

batch.addSource("tPersonalDocuments");

// 1

batch << SqlField("[ID]", fv_invisible, fr_id)

<< SqlField("LastName", fv_visible, fr_none, "", 120)

<< SqlField("FirstName", fv_visible, fr_none, "", 120)

<< SqlField("ParentName", fv_visible, fr_none, "", 120)

<< SqlField("SerialNumber", fv_visible, fr_none, "", 45)

<< SqlField("Number", fv_visible, fr_none, "", 70)

<< SqlField("DocType_ID", fv_invisible)

// 2

<< SqlField("[ID]", SqlValue(30, fo_greater), fp_where)

<< SqlField("DocType_ID", SqlValue(1), fp_where);



// – . 0 .

SqlQueryDescriptor queryDescriptor(batch, sql_select, 0);









ご覧のとおり、 FROMのリストは SqlBatch :: addSource（）を使用して読み込まれ、フィールド、フィールド、フィールドがあります...簡単です。 SqlFieldクラスは、特定のフィールド、フィールドの役割、Qtのビューでの存在/不在、ビュー内の列のヘッダー、およびこの列の幅を担当するSqlBatchにロードされます （セクション1）。 たとえば、IDフィールドがキーであり、これは重要なポイントであり、キーロールfr_idを付与します。 それでも、ビューに表示されるべきではありません。つまり、レコード内のキーをユーザーから隠したいのです。 いいえ、非表示にしたくない場合は、誰も邪魔しないでください。セクション2でWHEREのフィルターについて説明し、他と区別するために、 列挙型SqlFieldPurposeに属するfp_whereパラメーターがあります。 フィルターの場合、フィールドと値（特別なクラスSqlValue）を指定する必要があります。 例では、整数値が表示されます。 ここに：



batch << SqlField("[ID]", SqlValue(30, fo_greater), fp_where);









比較ファンクター「more」が指定されていますが、ここでは：



batch << SqlField("DocType_ID", SqlValue(1), fp_where);









functorは指定されていないため、整数ではfo_equalがデフォルトで使用されます。

はい、はい、これはすべて良いですが、他のタイプ、特に文字列と日付はどうですか？ すべてが可能です！ SQLクエリのこれらのスニペットは次のとおりです。



FirstName LIKE '%'

AND

Birthday BETWEEN convert(datetime '20.01.2009', 104) AND

convert(datetime '15.05.2009', 104)









手のフリックでエレガントなラインに変わります：



batch << SqlField("FirstName", SqlValue("", fo_like, fb_right), fp_where)

<< SqlField("Birthday", SqlValue(QDate(2009, 1, 20)), SqlValue(QDate(2009, 5, 15)));









（日付の変換は、定数で指定されたテンプレートに従って自動的に行われます。）

WHEREセクションに加えて、単純なSELECTにはORDER BYおよびGROUP BYを 含めることができることを思い出してください。 SqlFieldクラスには、これらの場合のコンストラクターもあります 。



SqlField("Birthday", fp_order_by)

SqlField("Birthday", fp_group_by)









（確かに、 GROUP BYの場合、集計関数とそれらに関与するフィールドのみを指定する必要がありますが、有効なSQLクエリを取得するかどうかはプログラマの良心に任せます。）

クエリ自体は、 SqlGenクラスとSqlQueryComposerクラスによって生成されます 。 実際、 SqlQueryComposerのみが生成し、 SqlGenはフィールドの順序を決定し、生成用の高レベルインターフェイスを提供します。 （ちなみに、必要に応じて、 SqlQueryComposerクラスを別のSQLダイアレクトに書き換えることができます。）フィールドで埋められたSqlBatchクラスを渡してSELECTクエリを取得する方法は次のとおりです。



SqlGen gen;

QString selectQuery = gen.query(batch, sql_select);









そして、 sql_selectの代わりに何か他のもの、例えばsql_updateを書くと、ジェネレータはUPDATEクエリを生成しようとし、許可されたフィールドのみを取得します。 どれ？ まあ、 |の代わりにSqlFieldPurposeパラメーターを持つもの 他の人と一緒に。 そのようなフィールドの例を次に示します。



SqlField("Age", SqlValue(10), fp_where | fp_update | fp_insert)









したがって、 sql_updateを使用すると、「SET Age = 10」のような画像が表示され、 sql_insertを使用すると次のようになります。



INSERT INTO … (Age)

VALUES (10)









その他すべての場合-WHEREの単なるフィルター：



WHERE

Age = 10









DFD記述子の概念は明確になり始めていますか？ そして、それが他のアプローチと非常に似ていることは事実です。 オリジナルを作りたくなかった...



しかし、これはすべてゴミです。 質問は異なります-ゴミの使い方 ここでは、実際には、アメニティが表示される場所について、上記のすべてを読みました。

AbstractModelHandler

私のライブラリにはいくつかの抽象クラスAbstractModelHandlerがあります。 それには多くの良いものが含まれており、DFD記述子でそれ以上にうまく機能するものはありません。 プログラマが軍事サービステーブルtArmyTypesを使用して作業をカプセル化したいとします。 これを行うために、彼はh_ArmyTypesHandler下位クラスを作成します。



const int ARMY_TYPES_QUERY = 7575;



class h_ArmyTypesHandler : public AbstractModelHandler

{

public:

h_ArmyTypesHandler();



private:



virtual SqlQueryDescriptor _selector(const SqlQueryModelTypes &modelType = mt_plain, const int &queryNumber = 0) const;

virtual SqlQueryDescriptor _inserter(const int &queryNumber = 0) const;

virtual SqlQueryDescriptor _updater(const int &queryNumber = 0) const;

virtual SqlQueryDescriptor _deleter(const int &queryNumber = 0) const;

virtual SqlQueryDescriptor _executor(const int &queryNumber = 0) const;

};









仮想関数_selector（）、_ inserter（）、updater（）、_ deleter（）、および_executor（）は 、基本クラスから継承されます。 これらにはDFD記述子が含まれており、他のAbstractModelHandlerの関数の要求で発行します。 たとえば、 以下は_selector（）関数の典型的なオーバーライドです。



SqlQueryDescriptor h_ArmyTypesHandler::_selector(const SqlQueryModelTypes &modelType, const int &queryNumber) const

{

SqlBatch batch;



batch.addSource("tArmyTypes");



if (queryNumber == ARMY_TYPES_QUERY)

{

batch << SqlField("ID", fv_invisible, fr_id)

<< SqlField("ShortName", fv_visible, fr_none, "", 90)

<< SqlField("Name", fv_visible, fr_none, " ", 100)



<< SqlField("ID", value(ID_VALUE), fp_where)

<< SqlField("Name", value("Name"), fp_where)

<< SqlField("ShortName", value("ShortName"), fp_where);

}

else

if (queryNumber == LAST_ID)

{

batch << SqlField("max(ID)", fv_visible, fr_none);

}

else

{

Q_ASSERT(false);

}



return SqlQueryDescriptor(batch, sql_select, queryNumber);

}









ここに新しいものがあります：特定の関数値（）です。 おそらく誰かが、以前に記録されたSqlValue（）値を名前で返すことを既に推測していたかもしれません。たとえば、フォームクラスのどこかでh_ArmyTypesHandlerに渡されます 。



h_ArmyTypesHandler th;

th.setValue("Name", SqlValue("__", fo_not_equal, fb_none));









つまり、目的の名前でsetValue（）関数を使用して値を保存し、（ AbstractModelHandlerクラスから）value（）関数を使用して記述子で値を取得します。 これで、要求を生成するときに、パラメーター化されたDFD記述子が作成されます。



この例の最後から2行目は、 SqlQueryDescriptorクラスのコンストラクターの3番目のパラメーターを示しています。これは要求番号です。 同じ_selector（）関数を使用して、少なくとも2つ、少なくとも10の異なる要求を生成できます。状況ごとに異なる要求があります。 そしてそれは良いことです。 そのようなフィールドが必要になったら、また別の機会に。 次に、集計関数を使用してクエリを呼び出し、クエリだけの場合は間違ったテーブルから呼び出します。 DFD記述子ごとにリクエスト番号を決定するだけで十分です。

これにより、一般にSQLクエリを生成および実行する方法の論理的な問題が発生します。 さて、例えば、このように：



…

const int ARMY_TYPE_INSERT_QUERY = 5;

const int ARMY_TYPE_UPDATE_QUERY = 68;

…



h_ArmyTypesHandler th;

th.setValue("Name", SqlValue("__", fo_not_equal, fb_none));

th.Insert(ARMY_TYPE_INSERT_QUERY);



th.setValue(ID_VALUE, SqlValue(10));

th.Update(ARMY_TYPE_UPDATE_QUERY);

th.Delete(4);









この場合、対応する関数が呼び出されます： _inserter（） 、 _updater（）および_deleter（） 、記述子が配置されています。 次に、ハンドラーの抽象親がSQLを生成し、Qtを使用して実行します。 すべてがシンプルです。



ただし、選択の結果を確認する必要があるため、多くの場合、ボイドを満たしていないSELECTクエリを使用する必要があります。 たとえば、TableViewが軍事支部のテーブルを表示することを望みます。 問題ありません！



...しかし、最初の後退。 Qtは、 QTableViewのデータモデルを必要とするMVCパターンの種類の1つを実装します 。 これらはQt自体にありますが、独自に行うことができます。 私は自分のモデルのプログラミングに強くないことを正直に認めますが、ライブラリについては、私が本当に見逃した最も単純なツリーモデル-SqlTreeModelを書きました 。 はい、Qtには要件を満たすツリーモデルがありません。または、あまり知りません。 QSTには、 SqlTreeModelとSqlQueryModelの 2つのモデルがあり、後者はQSqlQueryModelとわずかに異なるだけで、それを継承しています。 モデルは、 AbstractModelHandlerクラスで積極的に使用されています。



次に、QSTライブラリの別の概念であるデータソースを詳しく調べる必要があります。 これは実際、DFD-モデル-ビューの束です。 各データソースには名前が付けられ、名前はプログラマーによって設定されます。 TableViewで軍事支社のテーブルを表示するには、フォームクラスでデータソースを作成します。



…

h_ArmyTypesHandler _handler;

SqlQueryModel _model;

…



void f_ArmyTypesForm::loadArmyTypes()

{

_handler.reloadSource(ARMY_TYPES_SOURCE, ARMY_TYPES_QUERY, &_model);

_handler.setTableView(ARMY_TYPES_SOURCE, ui->TableView);

}









そしてそれだけです。 指定された幅とヘッダーを持つ列がTableViewに表示されます。 したがって、これらのパラメーターは、 h_ArmyTypesHandler :: _ selector（）関数で設定されます。 表示された列をリストします。「ShortName」という名前は「Abbreviation」、幅は90です。 名前が「Troops」で幅が100の「Name」。ただし、fv_invisibleがあるため、「ID」フィールドは表示されません。つまり、 reloadSource（）およびsetTableView（）関数は、プログラマーのテーブルフォーマットのルーチン全体を実行します。

ARMY_TYPES_SOURCEは、新しいデータソースのテキスト名です。 確かに、loadArmyTypes（）を再度呼び出すと、ソースは「 補充 」されます。_selector（）関数が再度呼び出され、 SELECT要求が再度生成され、データモデルは古い行を削除してデータベースから新しい行を取得します。 次の関数を呼び出すと、2つの異なる行セットが取得されます。



void f_ArmyTypesForm::someFunc1()

{

_handler.setValue(ID_VALUE, SqlValue(10));

loadArmyTypes();

}



void f_ArmyTypesForm::someFunc2()

{

_handler.setValue(ID_VALUE, SqlValue(111, fo_less));

loadArmyTypes();

}









ええ、それは私には十分ではありません。 AbstractModelHandlerを使用すると、複数のデータソースを作成できます（そうでない場合、なぜそれらに名前を付けるのですか？！。）。 TableViewに加えて、フォームにTreeViewとComboBoxがあり、同じものを表示したいとします。 問題ありません！ 次のようなものを書いています。



…

h_ArmyTypesHandler _handler;

SqlQueryModel _model;

SqlQueryModel _modelPlainForTreeView;

SqlQueryModel _modelForComboBox;

…



void f_ArmyTypesForm::loadArmyTypes()

{

_handler.reloadSource(ARMY_TYPES_SOURCE, ARMY_TYPES_QUERY, &_model);

_handler.setTableView(ARMY_TYPES_SOURCE, ui->TableView);



_handler.reloadSource(TREE_VIEW_SOURCE, ARMY_TYPES_QUERY, &_modelPlainForTreeView);

_handler.setTreeView(TREE_VIEW_SOURCE, ui->TreeView);



_handler.reloadSource(COMBO_BOX_SOURCE, ARMY_TYPES_QUERY, &_modelForComboBox);

_handler.setComboBox(COMBO_BOX_SOURCE, ui->ComboBox);

}









それで、あなたは尋ねます。 どう？ 異なるモデルが送信されていますか？ 違う。 したがって、3つのデータソースもあります。 ハンドラのみが一般的で、queryNumberは同じです-ARMY_TYPES_QUERY、したがって、同じクエリが生成されます。 しかし、私たちは魔法のことをすることができます！ たとえば、次のとおりです。



// ComboBox:

QVariant id = _handler.keyValueOfCurrent(ARMY_TYPES_SOURCE, ui->ComboBox);



// TreeView:

QVariant id2 = _handler.keyValueOfView(TREE_VIEW_SOURCE);



// Name ID == id2:

h_ArmyTypesHandler th;

th.setValue(ID_VALUE, SqlValue(id2));

QVariant name = th.SelectToValue("Name", ARMY_TYPES_QUERY);



// TableView ( ):

_handler.DeleteCurrent(ARMY_TYPES_SOURCE, ui->TableView);









さらに、リストでデータを選択することもできます。



h_ArmyTypesHandler th;

th.setValue(ID_VALUE, SqlValue(id2));



QVariantMap valMap = th.SelectToMap(QStringList() << "Name" << "ShortName" << "ID", ARMY_TYPES_QUERY);



ui->LineEdit_Name->setText(valMap["Name"].toString());









コード内の単一のSQLクエリではありません！ なんてこと!!!

そして結論として...

もちろん、私は多くの詳細を明らかにしません。 そのような小さなライブラリでさえ、それらの十分以上のものがあります。 残念ながら、 QSTの多くはできません。 通常のツリーモデルは非常に不足しています。 エラーが発生している可能性があり、 QTreeView信号と対話するときに奇妙な動作をします。特定の条件下では、クラッシュし、他の誰かのメモリにクロールします。 エラーが見つかりません。 2つのQtフォーラムの人々に助けを求めた例もありますが、今のところ誰も何も言っていません。

DFDやより複雑なクエリには場所がありません。 今、 WHEREセクションにOR条件を追加する方法を考えています。 JOINについて考える必要があるかもしれませんが、これは非常に必要です。 利用可能な手段ではこれらの制限を回避することは不可能というわけではありません-SQL言語は多面的ですが、開発する必要もあります。

さらに、ライブラリには、データベース接続を操作するためのクラス（ DBConnection ）、およびtr（）関数のコーデックを設定するクラス（ キリル文字 ）が含まれています。 さて、ノードを操作する方法を借用した自作のTreeItem 。 私は正直、クラスが好きではありません。 そして、 SqlTreeModelは似ていません。 コードが散らばって新しく 削除されたとき、私はそれが好きではありません。 メモリを操作する場合、 「リソースを取得することは初期化です。 」という原則を通して。 見て、すべてを賢く書き直してください。 いつか。

この開発が助けてくれた人に本当に欲しいです。 そして、改善提案のためにコミュニティがバグを特定するのを手伝ってもかまいません。 QSTソースは、SourceForgeのアーカイブ（ こちら）にあります 。 ライセンスは無料、GPL v3およびLGPL v3です。 詳細については、 このスレッドを参照してください 。

興味のある方の質問にお答えできることを嬉しく思います。



よろしく

グラニン・アレクサンダー