SQLクエリをそのクエリの抽象表現に解析するparseQueryという関数があります。
クエリの抽象表現を取り、SQL クエリ文字列を返す関数を作成しようとしています。
2 番目の関数は何と呼ぶべきですか?
SQLクエリをそのクエリの抽象表現に解析するparseQueryという関数があります。
クエリの抽象表現を取り、SQL クエリ文字列を返す関数を作成しようとしています。
2 番目の関数は何と呼ぶべきですか?
あなたが望む動詞は「compose」だと思います。
parseの反対はserializeです
コンパイラ用語では、反対は「解析解除」です。具体的には、解析はトークンのストリームを抽象構文ツリーに変換し、逆解析は抽象構文ツリーをトークンのストリームに変換します。
作曲?クエリを解析するときは、それを構成要素 (トークンなど) に分割します。その逆は、パーツを文字列クエリに構成することです。
既存の命名を補完するために、composeQueryが最適に見えます。
しかし、一般的なケースでは、解析の反対はǝsɹɐdです
私はこれらのいずれかを使用します:
「シリアル化」はおそらくあなたが望む言葉だと思います。これは、プログラムからエクスポート (およびインポート) できるデータのテキスト表現を生成することを意味します。
「分析」の対義語は「合成」です。
ToQueryString()
間違いなくレンダリングします。
私はそれをconstructQueryと呼びます。
おそらく、生成または放出します。
いくつかのものを追加するだけです。
確かに解析は双方向の言葉です。
要約をクエリに解析できます。
クエリを要約に解析できます。
問題は、メソッドの後半部分に何と名前を付けるかということです。この例では、abstract を解析してクエリを作成しているため、それを と呼びますparseAbstract
。
質問に答えるために、解析には反対はありません。
おそらく、generateQuery?createQuery?
好きなのを選びな
それぞれ微妙に異なる意味合いを持っています。
クラスとそれに関連する演算子の性質に応じて、compose、construct、generate、render、condense、reduce、toSQL、toString
従来のコンパイラには、パーサーとコード ジェネレーターの 2 つの部分があります。
したがって、「生成」と呼ぶことができます。もちろん、コンパイラはソース コードを記述していないため、ここでは少し異なります。(プリコンパイラでない限り)。
おそらくFormat()。またはあなたのインスタンスでToSQL()?
unParse()? 冗談ですが、toQueryString() を使用します
解析して...ではなく、シリアル化して逆シリアル化すると言います。
通常、それらをチェーンネストできるため、ToString()に行きます(反対の関数で、Class1からClass2に、またはその逆に渡すことができます)
DateTime.Parse( DateTime.Parse( myDate.ToString() ).ToString() );
Serialize() は良い選択のように見えますが、Deserialize() にはすでに反対の機能があります。
あなたの特定のシナリオでは、他の人が指摘したように、 ToSql() も別の良い選択です。
平らにする?
解析されたクエリ オブジェクトは、おそらく条件階層を表しており、これを「フラット化」して 1 次元の文字列に戻しています。
しかし、オブジェクトから文字列に移行する場合、実際には toString や toSQL() などを使用するだけです。さらに、適切に設計し、適切なアプリを使用している場合は、後で名前を変更して、コメントに何かを貼り付けることができます.
レンダリングを使用します
> a = 'html': { 'head': {'title': 'My Page'}, 'body': { 'h1': 'Hello World', 'p': 'This is a Paragraph' } }
> b = render(a)
> console.log(b)
<html>
<head>
<title>My Page</title>
</head>
<body>
<h1>Hello World</h1>
<p>This is a Paragraph</p>
</body>
</html>
私見ですが、parse() の反対です。
> c = parse(b)
{ 'html': {
'head': {
'title': 'My Page'
}
'body': {
'h1': 'Hello World',
'p': 'This is a Paragraph'
}
}
asSQL() またはさらに asQuery() についてはどうですか?
INHO シリアル化、合成は適切なオプションです。また、あなたがparseQueryと名付けたように、私はcodeQueryを使います
生成には+1しますが、生成しているもの、つまりGenerateSQL()に追加します
私は「作成」に投票しましたが、それが気に入らない場合は「ビルド」もお勧めします
デパース
Deparse は、次のように解析することです。
解析/逆解析は構造の変更ではなく、変換です。すべての関係と構造を維持しながら、同等のテキストと抽象構文ツリー形式の間で正確な変換を行います。
「構成」は構造の変更を意味するため、正確ではありません。別々の独立した部分から組み合わせることを示唆しています (通常は初めて)。「分解」が独立した部分に分割することを示唆しているように。形式だけでなく、形も変化します。
クイック検索では、用語が使用されている範囲が次のように表示されます。
.GetSqlQuery()
私の選択だろう
writeQuery. 解析は、文字列からそれを読み取り、オブジェクト (「実際の」としましょう) 表現を作成する行為です。反対は、オブジェクトを文字列に書き込むことです。
あなたが探している答えは次のとおりだと思います:「そもそも SQL を解析したり、SQL をアセンブルしたりしないでください。オブジェクト/リレーショナル マッパーを使用し、かなり長い間解決されてきた問題を解決して雇用主のお金を浪費するのをやめてください。 "