[[JHIPSTER一覧]]

*** 目次 [#n96aa4b5]
#contents


* JHipsterドメイン言語(JDL) [#z4f90135]
** JDLの概要 [#hbdeb56a]
JDLはJHipster固有のドメイン言語です。すべてのアプリケーション、デプロイメント、エンティティ、およびそれらの関係を単一のファイル(または複数のファイル)にシンプルでユーザーフレンドリーな構文で記述できます。


** このページの原文(英語) [#r07a176c]
https://www.jhipster.tech/jdl/

このページは、上記原文の、googleの日本語訳を手直(googleの翻訳そのまま+pukiwiki用に、ちょっと整形)したものになります。

どなたでも、編集可能です。気に入らない方は、どうぞ、修正をお願いします。


** JDL Studio [#i86b2ec6]
https://start.jhipster.tech/jdl-studio/


** プレビュー機能 [#r8ac8106]
JDLファイルとそのUMLビジュアライゼーションを作成するには、Eclipse、VS Code、Atom用のオンラインJDL-StudioまたはJHipster IDEプラグイン/拡張機能のいずれかを使用できます。JDLモデルのURLを作成してエクスポートまたは共有することもできます。

実行することで、import-jdlサブジェネレータを使用してJDLファイルからアプリケーション、デプロイメント、およびエンティティを生成できますjhipster import-jdl your-jdl-file.jdl。

既存のプロジェクト(コマンドラインをjhipster import-jdl使用して作成または生成さjhipsterれたプロジェクト)がある場合は、runningを実行してプロジェクトのエンティティを生成できますjhipster import-jdl your-jdl-file.jdl。このコマンドは必ずJHipsterプロジェクトの下で実行してください。

生成したJHipsterアプリケーションのルートから実行することで、JHipster UMLを使用してアプリケーションやエンティティを生成し、それらをJDLファイルとしてエクスポートすることもできjhipster-uml your-xmi-file.xmi --to-jdlます。JHipster UMLについてさらに学び、それをインストールするには、JHipster UMLの資料を参照してください。

これはエンティティサブジェネレータを使用する代わりに使用でき、推奨されるアプローチです。考え方は、古典的なYeomanの質問と回答よりも、ビジュアルツールを使用して関係を管理する方がはるかに簡単であるということです。

JDLプロジェクトはGitHubで利用可能です、それはJHipster(Apache 2.0ライセンス)のようなオープンソースプロジェクトです。JDL構文解析を行うためのノードライブラリとしても使用できます。

あなたがJHipsterドメイン言語のJDLを気に入ってくれたら、GitHubに、スターの評価を投票してくださいね。

* JDLサンプル [#ba008a05]
Oracleの「Human Resources」サンプルアプリケーションはJDLに翻訳されており、ここから

https://github.com/jhipster/jdl-samples/blob/master/Oracle-Human-Resources-sample.jdl

入手できます。同じアプリケーションがJDL-StudioとJHipster IDEにもデフォルトでロードされます。

もっとサンプルを探しているのなら、ここ

https://github.com/jhipster/jdl-samples

にそのためのリポジトリがあります。

** どうやって使うのですか [#f4753b46]
*** JDLファイルのインポート [#a32e46e4]
その後、JDLファイルを使用してエンティティを生成できます。

- 拡張子が「.jh」または「.jdl」のファイルを作成するだけです。
- アプリケーション、デプロイメント、エンティティ、および関係を宣言するか、JDL-Studio


実際に使えるやつ

https://start.jhipster.tech/jdl-studio/

またはJHipster IDE(Eclipse VSCode Atomでのインストール動画あり)

https://www.jhipster.tech/jhipster-ide/

でファイルを作成してダウンロードします。
- エンティティのみを作成している場合jhipster import-jdl my_file.jdlは、JHipsterアプリケーションのルートフォルダで実行してください。
- アプリケーションを作成している場合jhipster import-jdl my_file.jdlは、フォルダ内で実行するだけです。

チームで作業している場合は、おそらく1つではなく複数のファイルを使用したいと思うでしょう。このオプションを追加したので、手動ですべてのファイルを1つに連結するのではなく、実行するだけで済みます。

 jhipster import-jdl my_file1.jdl my_file2.jdl

JDLのインポート中にエンティティを再生成したくない場合は、--json-onlyフラグを使用してエンティティ作成部分をスキップし、.jhipsterフォルダ内にjsonファイルのみを作成できます。

 jhipster import-jdl ./my-jdl-file.jdl --json-only
デフォルトimport-jdlでは、変更されたエンティティだけが再生成されます。すべてのエンティティを再生成する場合は、--force フラグを渡します。これにより、エンティティファイルに対するローカルの変更がすべて上書きされます。

 jhipster import-jdl ./my-jdl-file.jdl --force
あなたがあなたのプロジェクトでそれを使いたいならば、あなたはそうすることによってそうすることを加えることができます:

- NPM: npm install jhipster-core --save
- 糸: yarn add jhipster-core

ローカルにインストールしてpackage.jsonファイルに保存します。

** JDLファイルへのエクスポート [#l64c423a]
アプリケーションに既にエンティティがあり、JDLファイルを取得したい場合は、そうしないでください。あなたのためにそれをするサブジェネレータがあるので、あなたは最初からそれを書く必要はありません。

jhipster export-jdl <FILE_NAME>アプリのルートフォルダで実行するだけで、すべてのエンティティ、関係、およびオプションのエクスポートが1つのJDLファイルにまとめられます。注:サブ世代にファイル名を指定することもできません。デフォルトのものが選択されます。

* 言語 [#e9612a06]
私たちは開発者にとってできるだけフレンドリーな構文を保つようにしました。あなたはそれでこれらのことをすることができます:

- アプリケーションをそのオプションとエンティティで宣言します。
- エンティティをその属性で宣言します。
- それらの間の関係を宣言する、
- そしてJHipster特有のオプションをいくつか宣言します。

JDLの文法を見たいのであれば、ここ

https://github.com/jhipster/jhipster-core/blob/master/lib/dsl/gen/grammar.html

に HTMLファイルがあり ます。

** アプリケーション宣言 [#r1dec1e8]
v2.0.0以降、アプリケーションの宣言は可能です(JHipster v5と互換性があります)。

1つまたは複数のアプリケーションをインポートするために、JHipsterアプリケーションフォルダにいる必要はありません。

最も基本的な宣言は次のように行われます。

 application {
   config {}
 }
JHipsterアプリケーションにはデフォルト値の設定があり、前の構文を使用すると、アプリケーションがデフォルト値を使用するようになります(特に選択しなかった場合と同じ)。結果のアプリケーションは以下のようになります。

- baseName: jhipster
- アプリケーションタイプ: monolith
- databaseType: sql
- 等
今、あなたはいくつかのカスタムオプションが必要な場合:

 application {
   config {
     baseName myapp
     applicationType microservice
     prodDatabaseType postgresql
     buildTool gradle
   }
 }
これらのオプションは、JDLで利用可能なもののほんの一例です。オプションの完全なリストは、ここの付録にあります。

複数のアプリケーションが必要な場合は、次のようにします。

 application { // will be generated under the 'myFirstApp' folder
   config {
     baseName myFirstApp
   }
 }

 application { // will be generated under the 'mySecondApp' folder
   config {
     baseName mySecondApp
     applicationType microservice
   }
 }
あなたはあなたが望むだけ多くのファイルにあなたが望むだけの数のアプリケーションを持つことができます。制限はありません。

エンティティの宣言は利用可能な最も基本的なものであり、今、あなたは欲しいアプリケーションでどのエンティティが生成されるべきかを設定することができます。

前の例を改良しましょう。

 application {
   config {
     baseName myMonolith
     applicationType monolith
   }
   entities * except C, D
 }
 
 application {
   config {
     baseName myGateway
     applicationType gateway
     serverPort 9042
   }
   entities * except A, B
 }

 application {
   config {
     baseName microserviceA
     applicationType microservice
   }
   entities C
 }

 application {
   config {
     baseName microserviceB
     applicationType microservice
     serverPort 8082
   }
   entities D
 }
 
 entity A
 entity B
 entity C
 entity D
 
 dto * with mapstruct
 service * with serviceClass
 paginate D with pager
これらのアプリケーションとフォルダを生成すると、いくつかのことが起こります。

- 4つのアプリケーションが作成されます。
-- myMonolithの中./myMonolith、サーバーのポート番号8080
-- myGateway ./myGateway、サーバーポートあり9042
-- サーバー./microserviceAポートとともに、microserviceA in8081
--- サーバーポートを指定していなくても、JHipsterはデフォルトでポートを設定します。
--- マイクロサービスの場合、デフォルトのものは 8081
--- ゲートウェイとモノリスの場合、それは 8080
--- UAAアプリの場合、それは 9999
-- サーバー./microserviceBポートと一緒にmicroserviceB8082
- 4つのエンティティが生成されます
-- AそしてBモノリスの中で
-- CそしてDゲートウェイの両方
--- C 最初のマイクロサービスで
--- D 2番目のマイクロサービス
- このmicroserviceオプションはCand に対して暗黙的ですD
-- これらは2つのマイクロサービスで生成されるため、このオプションはデフォルトで設定されます。
- オプションは以前と同じように機能します

デフォルト値が存在しない場合、ジェネレータはデフォルト値を設定します(のようにdatabaseType)。JHipster Coreでもまったく同じことができます。

** エンティティ宣言 [#g41f40bd]
エンティティ宣言は次のように行われます。

 entity <entity name> {
   <field name> <type> [<validation>*]
 }
- <entity name> エンティティの名前です。
- <field name> エンティティの1つのフィールドの名前
- <type> JHipsterがサポートしているフィールドの型
- オプションとして<validation>フィールドの検証。

可能なタイプと検証はここで説明されているものです、検証が値を必要とするならば、単に(<value>)検証の名前の直後に追加してください。

これがJDLコードの例です。

 entity A
 entity B
 entity C
 entity D {
   name String required
   address String required maxlength(100)
   age Integer required min(18)
 }
正規表現は(v1.3.6から)このように使われているのでちょっと特別です。

 entity A {
   myString String required minlength(1) maxlength(42) pattern(/[A-Z]+/)
 }
v4.9.Xより前のジェネレータを使用している場合は、このようなパターンを使用する必要がありますpattern('[A-Z]+'。

JDLは使いやすく読みやすいように作られているので、もしあなたのエンティティが空(フィールドなし)なら、あなたはエンティティをentity Aorで宣言することができますentity A {}。

JHipsterはデフォルトのidフィールドを追加しているので、心配する必要はありません。

** 関係宣言 [#d6283bed]
関係の宣言は次のように行われます。

 relationship (OneToMany | ManyToOne | OneToOne | ManyToMany) {
   <from entity>[{<relationship name>[(<display field>)]}] to <to entity> [{<relationship name>[(<display field>)]}]
 }

- (OneToMany | ManyToOne| OneToOne | ManyToMany) あなたの関係のタイプは
- <from entity> 関係のエンティティ所有者の名前です。ソース、
- <to entity> 関係が移動するエンティティの名前です。
- <relationship name> 型としてもう一方の端を持つフィールドの名前です。
- <display field>選択ボックスに表示すべきフィールドの名前です(デフォルトは:id)、
- required 注入されたフィールドが必要かどうか
- with jpaDerivedIdentifier@MapsId関連付けに使用されるかどうか(1対1にのみ適用可能)

これは簡単な例です:

 entity Book
 entity Author
 
 relationship ManyToOne {
   Book to Author
 }
必要に応じてデフォルトで一方(または両方)が設定されるため、注入フィールドの宣言はオプションです。前の例はこれと同じです。

 entity Book
 entity Author
 
 relationship ManyToOne {
   Book{author} to Author
 }
もっと複雑にしましょう。本には必要な著者が1人、著者には複数の本があります。

 entity Book
 entity Author {
    name String required
 }
 
 relationship OneToMany {
   Author{book} to Book{writer(name) required}
 }
ここでは、Bookクラスはのフィールドを通してリンクされるという名前の必須フィールドを持ちます。writernameAuthor

もちろん、実際のケースでは、たくさんの関係があり、いつも同じ3行を書くのは面倒です。だからこそ、次のように宣言できるのです。

 entity A
 entity B
 entity C
 entity D
 
 relationship OneToOne {
   A{b} to B{a}
   B{c} to C
 }
 relationship ManyToMany {
   A{d} to D{a}
   C{d} to D{c}
 }

結合は常にidフロントエンドでリレーションを編集するときに表示されるデフォルトフィールドでもあるフィールドを使用して行われます。代わりに別のフィールドを表示する必要がある場合は、次のように指定できます。

 entity A {
   name String required
 }
 entity B
  
 
 relationship OneToOne {
   A{b} to B{a(name)}
 }

JPA派生識別子 - @MapsIdは以下のように宣言することができます。現在のところ1対1でのみサポートされています。

 entity A {
   name String required
 }
 entity B
  
 
 relationship OneToOne {
   A{b} to B{a(name)} with jpaDerivedIdentifier
 }

これはJHipster、両方返すRESTリソースを生成させるidとname名前ではなく、ユーザに示すことができるように、フロントエンドに連結されたエンティティのを。

** 列挙型 [#jdfaf91e]
JDLを使ってEnumを作るには、次のようにします。

- ファイル内の任意の場所にEnumを宣言します。

  enum Language {
    FRENCH, ENGLISH, SPANISH
  }

- エンティティで、Enumを型として持つフィールドを追加します。

  entity Book {
    title String required,
    description String,
    language Language
  }
** ブロブ(byte []) [#z5a08db9]
JHipsterは、イメージタイプと任意のバイナリタイプの間で選択できるので、素晴らしい選択をします。JDLを使えば同じことができます。エディタを使ってカスタムタイプ(DataTypeを参照)を作成し、次の規約に従って名前を付けます。

- AnyBlobまたは単にBlob「任意」のバイナリ型のフィールドを作成すること。
- ImageBlob イメージであることを意味するフィールドを作成すること。
- TextBlob CLOB(テキスト(長))のフィールドを作成します。

そして、あなたは好きなだけデータ型を作成することができます。

** オプション宣言 [#ccb29bdb]
JHipsterでは、ページネーションやDTOなどのエンティティのオプションを指定できます。JDLでも同じことができます。

 entity A {
   name String required
 }
 entity B
 entity C
 
 dto A, B with mapstruct 
 
 paginate A with infinite-scroll
 paginate B with pagination
 paginate C with pager  // pager is only available in AngularJS
 
 service A with serviceClass
 service C with serviceImpl
キーワードはdto、paginate、serviceおよびwithこれらの変更をサポートするために、文法に追加されました。間違ったオプションが指定された場合、JDLはそれを素敵な赤いメッセージで知らせ、JHipsterのJSONファイルを破損しないように無視します。

*** サービスオプション [#kaec1a88]
指定されたサービスは、リポジトリインタフェースを直接呼び出すリソースクラスを作成しません。これはデフォルトで最も単純なオプションです。Aを参照してください。serviceClass(Bを参照)を使用したサービスでは、リソースがサービスクラスを呼び出し、リポジトリクラスが呼び出されます。serviceImpl(Cを参照)を使用したサービスは、リソースクラスによって使用されるサービスインタフェースを作成します。このインタフェースは、リポジトリインタフェースを呼び出す具象クラスによって実装されます。

確実でない限り、サービスを使用しないのが最も簡単な方法であり、CRUDに適しています。複数のリポジトリを使用することでサービスクラスに最適なビジネスロジックが多数ある場合は、Class with serviceを使用します。Jhipsterは不要なインターフェースのファンではありませんが、気に入った場合はimplでサービスを受けてください。

 entity A
 entity B
 entity C
 
 // no service for A
 service B with serviceClass
 service C with serviceImpl

JDLはマスオプション設定もサポートします。それはすることは可能です:

 entity A
 entity B
 ...
 entity Z
 
 dto * with mapstruct
 service all with serviceImpl
 paginate C with pagination

なお*とall同等です。最新バージョンでは除外されています(すべてのエンティティにオプションを設定する際に非常に強力なオプションです)。

 entity A
 entity B
 ...
 entity Z
 
 dto * with mapstruct except A
 service all with serviceImpl except A, B, C
 paginate C with pagination

JHipsterを使用すると、クライアントコードやサーバーコードが不要かどうかもわかります。Angular関連のファイルにサフィックスを追加したい場合でも、JHipsterでそれを実行できます。 フィルタオプションは、エンティティごとにアクティブにすることができます:フィルタ<entity name>またはすべてのエンティティに対してフィルタ:フィルタ*。あなたのJDLファイルに、同じことをするために単にこれらの行を追加してください:

 entity A
 entity B
 entity C 
 
 skipClient A
 skipServer B
 angularSuffix * with mySuperEntities
 filter C

最後に、テーブル名も指定できます(エンティティの名前がデフォルトで使用されます)。

 entity A // A is the table's name here
 entity B (the_best_entity) // the_best_entity is the table's name

** マイクロサービス関連のオプション [#n788a80a]
JHipster v3以降、マイクロサービスを作成できます。JDLでエンティティを生成するためのオプションをいくつか指定できます。マイクロサービスの名前と検索エンジンです。

マイクロサービスの名前(JHipsterアプリの名前)を指定する方法は次のとおりです。

 entity A
 entity B
 entity C
 
 microservice * with mysuperjhipsterapp except C
 microservice C with myotherjhipsterapp
 search * with elasticsearch except C
最初のオプションはJHipsterにあなたのマイクロサービスにあなたのエンティティを処理させたいことを伝えるために使われますが、2番目のオプションはあなたのエンティティをどのようにそしてあなたが検索したいかを指定します。

** アノテーション [#efc314c3]
注釈はJHipster v5以降で利用可能です。Javaで可能なことと同様に、アノテーションはアノテーションオプションであなたのエンティティにアノテーションを付けるように同じように働きます。

たとえば、このJDLコードを見てください。

 entity A
 entity B
 entity C
 
 dto C with mapstruct
 paginate * with pager except C
 search A with elasticsearch

これはアノテーションと同等です:

 @paginate(pager)
 @search(elasticsearch)
 entity A
 
 @paginate(pager)
 entity B
 
 @dto(mapstruct)
 entity C
これにより、実際に削除されるよりも多くのコードが追加されますが、複数のJDLファイルを使用する場合(マイクロサービスなど)には実際には便利です。

** デプロイメント宣言 [#nc352c25]
v3.6.0以降では、デプロイメント宣言が可能です(JHipster v5.7以降と互換性があります)。

1つまたは複数のデプロイメントをインポートするために、JHipsterアプリケーションフォルダーにいる必要はありません。

最も基本的な宣言は次のように行われます。

 deployment {
   deploymentType docker-compose
   appsFolders [foo, bar]
   dockerRepositoryName "yourDockerLoginName"
 }
JHipsterデプロイメントには他のすべてのプロパティのデフォルト値を含む設定があります。前の構文を使用すると、デプロイメントにデフォルト値が使用されるようになります(特に選択しなかった場合と同じ)。結果として得られるデプロイメントは以下のようになります。

- deploymentType: docker-compose
- appsFolders: foo, bar
- dockerRepositoryName: yourDockerLoginName
- serviceDiscoveryType: eureka
- gatewayType: zuul
- directoryPath: ../
- 等

今、あなたはいくつかのカスタムオプションが必要な場合:

 deployment {
   deploymentType kubernetes
   appsFolders [store, invoice, notification, product]
   dockerRepositoryName "yourDockerLoginName"
   serviceDiscoveryType no
   istio autoInjection
   kubernetesServiceType Ingress
   kubernetesNamespace jhipster
   ingressDomain "jhipster.192.168.99.100.nip.io"
 }
これらのオプションは、JDLで利用可能なもののほんの一例です。オプションの完全なリストは、ここの付録にあります。

複数の配置が必要な場合は、次のようにします。

 // will be created under 'docker-compose' folder
 deployment {
   deploymentType docker-compose
   appsFolders [foo, bar]
   dockerRepositoryName "yourDockerLoginName"
 }
 
 // will be created under 'kubernetes' folder
 deployment {
   deploymentType kubernetes
   appsFolders [foo, bar]
   dockerRepositoryName "yourDockerLoginName"
 }
deploymentTypeごとに1つのデプロイメントを持つことができます。で定義されているアプリケーションappsFoldersは、デプロイメントを作成しているのと同じフォルダー、またはで定義されているフォルダーになければなりませんdirectoryPath。たとえば上記の場合は、次のようなフォルダ構造が必要です。

 .
 ├── yourJdlFile.jdl
 ├── foo
 ├── bar
 ├── kubernetes // will created by the JDL
 └── docker-compose // will created by the JDL

* コメント&Javadoc [#c9803216]
JavadocとコメントをJDLファイルに追加することは可能です。

Javaと同じように、この例ではJavadocコメントを追加する方法を示します。

 /**
  * Class comments.
  * @author The JHipster team.
  */
 entity MyEntity { // another form of comment
   /** A required attribute */
   myField String required
   mySecondField String // another form of comment
 }
 
 /**
  * Second entity.
  */
 entity MySecondEntity {}
 
 relationship OneToMany {
   /** This is possible too! */
   MyEntity{mySecondEntity}
   to
   /**
    * And this too!
    */
   MySecondEntity{myEntity}
 }
これらのコメントは、後でJHipsterによってJavadocコメントとして追加されます。

JDLは独自のコメントを持っています。
 
 // an ignored comment
 /** not an ignored comment */
したがって、最初から始まるものはすべて//JDLの内部コメントと見なされ、Javadocとしてはカウントされません。

JDL Studioのディレクティブは#構文解析中に無視されます。

コメントの別の形式は以下のコメントです。

 entity A {
   name String /** My super field */
   count Integer /** My other super field */
 }
ここでAの名前はとMy super field、B はとコメントされMy other super fieldます。はい、コンマは必須ではありませんが、コードを間違えないようにするためにそれらを持つのが賢明です。カンマとそれに続くコメントを混在させる場合は、注意してください。

 entity A {
   name String, /** My comment */
   count Integer
 }
カウントがするので、Aの名前にはコメントがありません。

** すべての関係 [#rd873b27]
JDLとの関係を作成する方法についての説明。

*** 一対一 [#ob88e95f]
車に運転手がいて、運転手に車がある双方向の関係。

 entity Driver
 entity Car
 relationship OneToOne {
   Car{driver} to Driver{car}
 }
市民がパスポートを持っているが、そのパスポートがその所有者だけにアクセスすることができない単方向の例。

 entity Citizen
 entity Passport
 relationship OneToOne {
   Citizen to Passport
 }
 
 // using @MapsId
 relationship OneToOne {
       Citizen to Passport with jpaDerivedIdentifier
 }
*** 一対多 [#n2a26959]
所有者に1つ以上のCarオブジェクトがなく、Carがその所有者を知っている双方向の関係。

 entity Owner
 entity Car
 relationship OneToMany {
   Owner{car} to Car{owner}
 }
この関係の単方向バージョンはJHipsterではサポートされていませんが、次のようになります。

 entity Owner
 entity Car
 relationship OneToMany {
   Owner to Car
 }
*** 多対一 [#qbd0d4e1]
一対多の関係の相互バージョンは、以前と同じです。車がその所有者を知っている単方向バージョン:

 entity Owner
 entity Car
 relationship ManyToOne {
   Car to Owner
 }
*** 多対多 [#f2db90e1]
最後に、この例では、ドライバを知っているCarがあり、Driverオブジェクトはそのcarにアクセスできます。

 entity Driver
 entity Car
 relationship ManyToMany {
   Car{driver} to Driver{car}
 }

関係の所有側は左側になければならないことに注意してください

** 定数 [#sa8995c7]
JHipster Core v1.2.7以降、JDLは数値定数をサポートします。これが一例です。

 DEFAULT_MIN_LENGTH = 1
 DEFAULT_MAX_LENGTH = 42
 DEFAULT_MIN_BYTES = 20
 DEFAULT_MAX_BYTES = 40
 DEFAULT_MIN = 0
 DEFAULT_MAX = 41
 
 entity A {
   name String minlength(DEFAULT_MIN_LENGTH) maxlength(DEFAULT_MAX_LENGTH)
   content TextBlob required
   count Integer min(DEFAULT_MIN) max(DEFAULT_MAX)
 }

* ワークフロー [#vfeb8300]
** モノリスワークフロー [#z7d7a43a]
ここに特別なワークフローはありません。

- アプリケーションを作成する
- JDLファイルを作成します
- インポートする

** マイクロサービスのワークフロー [#vfb0e38e]
マイクロサービスを扱うのは少し面倒ですが、JDLにはエンティティを適切に処理するためのオプションがいくつかあります。

ではmicroservice <ENTITIES> with <MICROSERVICE_APP_NAME>、あなたはどのmicroserviceに生成されますどのエンティティを指定することができます。例えばこの設定をしてください:

 entity A
 entity B
 entity C
 
- microservice A with firstMS
- microservice B with secondMS

2つのJHipsterアプリケーション(「firstMS」と「secondMS」)があるとすると、2つのアプリケーションにJDLファイルをインポートすると、次のようになります。

- 'firstMS'では、エンティティAとCが生成されます。
- 「secondMS」では、エンティティBとCが生成されます。

Cなぜなら、このエンティティがどこで生成されるかを指定するマイクロサービスオプションがなければ、それはどこでも生成されるからです。このJDLをモノリスアプリケーションにインポートすることにした場合、すべてのエンティティが生成されます(モノリスにはJDLの制限オプションはありません)。

注:2つの異なるマイクロサービスで同じエンティティーを生成したい場合は、JDLファイルを更新する代わりに2つのJDLファイルを作成することができます。毎回。

前の例は、このように書かれたはずがありません。

 entity A
 entity B
 entity C 
 
 microservice * except B with firstMS
 microservice * except A with secondMS

これが結果です。

- 'firstMS'では、エンティティのみCが生成されます
- 「secondMS」では、エンティティBとCが生成されます。構文解析時に、あるオプションが別のオプションと重複する場合は、後者が優先されるためです。

JDLを使ってマイクロサービススタック全体を作成することもできます。例えば、このブログ記事

https://medium.com/jhipster/create-full-microservice-stack-using-jhipster-domain-language-under-30-minutes-ecc6e7fc3f77

を参照してください。

** 附属書 [#pa36af03]
*** 利用可能なアプリケーションオプション [#xc62a0d9]
JDLでサポートされているアプリケーションオプションは次のとおりです。

|JDLオプション名	|デフォルト値	|可能な値	|コメント|
アプリケーションタイプ	モノリス	モノリス、マイクロサービス、ゲートウェイ、UAA	
baseName	ジップスター		
パッケージ名	com.mycompany.myapp		packageFolderオプションを設定します
authenticationType	jwtまたはuaa	jwt、session、uaa、oauth2	UAAアプリの場合はuaa、それ以外の場合はjwt
uaaBaseName			認証タイプがuaaの場合、ゲートウェイおよびマイクロサービスには必須です。二重引用符で囲む必要があります。
buildTool	メイヴン	メイヴン、グラドル	
databaseType	SQL	sql、mongodb、cassandra、couchbase、いいえ	
devDatabaseType	h2ディスク	h2ディスク、h2メモリ、*	* + prodデータベースの種類
prodDatabaseType	MySQL	mysql、mariadb、mssql、postgresql、oracle、いいえ	
cacheProvider	ehcacheまたはhazelcast	ehcache、ヘーゼルキャスト、不定詞、no	モノリスおよびゲートウェイ用のehcache、それ以外の場合はhazelcast
enableHibernateCache	本当の		
clientFramework	角度X	angularX、反応する	
useSass	偽		
clientPackageManager	午後	npm、糸	
entitySuffix			エンティティのサフィックス。空の文字列の場合はfalseです。
dtoSuffix	DTO		DTOのサフィックス。空の文字列の場合はfalseです。
jhiPrefix	チ		
enableTranslation	本当の		
母国語	en	JHipsterでサポートされている任意の言語	
言語	[en、fr]	JHipsterで利用可能な言語	中括弧は必須です
enableSwaggerCodegen	偽		
serviceDiscoveryType	偽	ユーレカ、領事、いいえ	
messageBroker	偽	カフカ、偽	
検索エンジン	偽	elasticsearch、false	
サーバポート	8080、8081または9999		アプリの種類によります
ウェブソケット	偽	spring-websocket、false	
testFrameworks	[]	分度器、きゅうり、ガトリング	ブレース必須
skipClient	偽		
skipServer	偽		
skipUserManagement	本当の	
	
** 利用可能な展開オプション [#a86aefbd]
JDLでサポートされているアプリケーションオプションは次のとおりです。

|JDLオプション名	|デフォルト値	|可能な値	|コメント|
deploymentType	docker-compose	docker-compose、kubernetes、openshift	
directoryPath	「../」		相対パス 二重引用符で囲む必要があります
appsフォルダ	[]		アプリケーションのディレクトリ名をカンマで区切って指定します。リストでなければなりません。例[foo、bar]
clusteredDbApps	[]		クラスタDBを含むアプリケーションのディレクトリ名をカンマで区切って指定します。リストでなければなりません。例[foo、bar]
gatewayType	ズールー	ズールー、traefik	serviceDiscoveryTypeが `no`の場合、値は無視されます
モニタリング	いいえ	いいえ、ヘラジカ、プロメテウス	
consoleOptions	[]	[学芸員、ジップキン]	リストでなければなりません
serviceDiscoveryType	ユーレカ	ユーレカ、領事、いいえ	
dockerRepositoryName			dockerリポジトリの名前またはURL。二重引用符で囲む必要があります
dockerPushCommand	「ドッカープッシュ」		使用するdocker pushコマンド。二重引用符で囲む必要があります
kubernetesNamespace	デフォルト		deploymentTypeがkubernetesの場合にのみ適用可能
kubernetesServiceType	ロードバランサ	ロードバランサ、NodePort、入力	deploymentTypeがkubernetesの場合にのみ適用可能
ingressDomain			kubernetesServiceTypeが `Ingress`の場合のIngressのドメイン 二重引用符で囲む必要があります。deploymentTypeがkubernetesの場合にのみ適用可能
istio	いいえ	いいえ、manualInjection、autoInjection	deploymentTypeがkubernetesの場合にのみ適用可能
openshiftNamespace	デフォルト		deploymentTypeがopenshiftの場合にのみ適用されます。
storageType	はかない	はかない、しつこい	deploymentTypeがopenshiftの場合にのみ適用されます。

** 利用可能なフィールドタイプと制約 [#k0f4973f]
JDLでサポートされている型は次のとおりです。

** 共通データベース [#o5302051]

- PostgreSQL
- MySQL
- MariaDB
- オラクル
- MsSQL
- MongoDB
- カウチベース

|共通データベース	|カサンドラ	|検証|
ひも	ひも	必須、最小長、最大長、パターン、固有
整数	整数	必須、最小、最大、ユニーク
長いです	長いです	必須、最小、最大、ユニーク
BigDecimal	BigDecimal	必須、最小、最大、ユニーク
浮く	浮く	必須、最小、最大、ユニーク
ダブル	ダブル	必須、最小、最大、ユニーク
列挙型		必須、ユニーク
ブール値	ブール値	必須、ユニーク
LocalDate		必須、ユニーク
日付	必須、ユニーク
ZonedDateTime		必須、ユニーク
期間		必須、ユニーク
UUID	UUID	必須、ユニーク
ブロブ		必須、最小バイト数、最大バイト数、固有
AnyBlob		必須、最小バイト数、最大バイト数、固有
ImageBlob		必須、最小バイト数、最大バイト数、固有
TextBlob		必須、ユニーク
インスタント	インスタント	必須、ユニーク

** 利用可能なオプション [#b1ef7375]
*** 単項オプション [#g4c01a54]
これらのオプションには意味がありません。

- skipClient
- skipServer
- noFluentMethod
- filter

彼らはこのように使用することができます: <OPTION> <ENTITIES | * | all> except? <ENTITIES>

*** バイナリーオプション [#a63bd725]
これらのオプションは値を取ります。

- dto(mapstruct)
- service(serviceClass、serviceImpl)
- paginate(pager、pagination、infinite-scroll)
- search(elasticsearch)
- microservice (カスタム値)
- angularSuffix (カスタム値)
- clientRootFolder (カスタム値)

** トラブルシューティング [#t252e19f]
***JDLインポートは、MS baseNameと一致するときに1つのエンティティーのみを検出します [#h66ae45e]

これは構文解析システムに関する既知の問題であり、修正するのは難しいです。明らかな回避策は、マイクロサービスと内部のエンティティに異なる名前を使用することです。

詳細についてはJHipster Core issue#308

https://github.com/jhipster/jhipster-core/issues/308

を参照してください。

* 問題とバグ [#vf22b48b]
JDLはGitHub

https://github.com/jhipster/jhipster-core

から入手でき、JHipsterと同じ 貢献ガイドライン

https://github.com/jhipster/generator-jhipster/blob/master/CONTRIBUTING.md

に従っています。

図書館自体に関する問題やプルリクエストを提出するために私たちのプロジェクトを使ってください。

- JDL課題追跡システム [#l70d7bf2]

https://github.com/jhipster/jhipster-core/issues


- JDLプルリクエスト

https://github.com/jhipster/jhipster-core/pulls

何かを送信するときは、できるだけ正確にする必要があります。

- 1つの投稿された号には1つの問題


- プルリクエストは歓迎されていますが、実際に理解できるようにするためにはコミットは 'アトミック'でなければなりません。

* 翻訳者注:さいごに [#ad5859bf]
このページは、だれでも、編集可能にしてあります。

googleの翻訳をベースに、作成してありますが、加筆修正など、

気づいたらお願いします。

* 練習してみる [#o76fd13c]
以下、訳者の練習ターンです。
さて、翻訳は、だいだいこの辺にしておいて、エンティティを作ってみようと思います。

JDLのサンプルって、HelloWorldにしては、ちょっと、おおきいじゃないですか。

まずは、小さく、やってみたら、どうなるか。実験してみましょうか。

https://start.jhipster.tech/jdl-studio/

を開いて、既存のコードをバッサリ消して、下記のコードをいれてみます。

 // AEntityComment
 entity AEntity {
     // AEntityNameComment 
 	aEntityName String
 }

右上のダウンロードボタンを押すと、jhipster-jdl.jhがダウンロードされます。

自分のアプリのフォルダにこの、ダウンロードしてきたファイルをもってきて、
 
 jshipster import-jdl さっきダウンロードしたファイル名

で、--forceオプションつけとかなかったので、いろいろ上書き確認されてしまった。

*** 1個のエンティティ作成の結果はこんな感じ [#k0eff1f2]
 Found the .jhipster/AEntity.json configuration file, entity can be automatically generated!
 

 The entity AEntity is being updated. 
 
      info Using blueprint generator-jhipster-vuejs for entity-client subgenerator
    create 
  src\main\resources\config\liquibase\changelog\20190719011806_added_entity_AEntity.xml
    create src\main\resources\config\liquibase\data\a_entity.csv
    create src\main\java\com\mycompany\myapp\domain\AEntity.java
    create src\main\java\com\mycompany\myapp\repository\AEntityRepository.java
    create src\main\java\com\mycompany\myapp\web\rest\AEntityResource.java
    create src\test\java\com\mycompany\myapp\web\rest\AEntityResourceIT.java
  conflict src\main\resources\config\liquibase\master.xml
 ? Overwrite src\main\resources\config\liquibase\master.xml? overwrite
     force src\main\resources\config\liquibase\master.xml
  conflict src\main\java\com\mycompany\myapp\config\CacheConfiguration.java
 ? Overwrite src\main\java\com\mycompany\myapp\config\CacheConfiguration.java? 
 overwrite
     force src\main\java\com\mycompany\myapp\config\CacheConfiguration.java
    create src\main\webapp\app\entities\a-entity\a-entity-details.vue
    create src\main\webapp\app\entities\a-entity\a-entity-update.vue
    create src\main\webapp\app\entities\a-entity\a-entity.vue
  conflict src\main\webapp\app\core\jhi-navbar\jhi-navbar.vue
 ? Overwrite src\main\webapp\app\core\jhi-navbar\jhi-navbar.vue? overwrite
     force src\main\webapp\app\core\jhi-navbar\jhi-navbar.vue
    create src\main\webapp\app\entities\a-entity\a-entity-details.component.ts
    create src\main\webapp\app\entities\a-entity\a-entity-update.component.ts
    create src\main\webapp\app\entities\a-entity\a-entity.component.ts
    create src\main\webapp\app\entities\a-entity\a-entity.service.ts
    create src\main\webapp\app\shared\model\a-entity.model.ts
    create src\test\javascript\spec\app\entities\a-entity\a-entity.component.spec.ts
    create src\test\javascript\spec\app\entities\a-entity\a-entity-detail.component.spec.ts
    create src\test\javascript\spec\app\entities\a-entity\a-entity- update.component.spec.ts
    create src\test\javascript\spec\app\entities\a-entity\a-entity.service.spec.ts
  conflict src\main\webapp\app\router\index.ts
 ? Overwrite src\main\webapp\app\router\index.ts? overwrite
     force src\main\webapp\app\router\index.ts
  conflict src\main\webapp\app\main.ts
 ? Overwrite src\main\webapp\app\main.ts? overwrite
     force src\main\webapp\app\main.ts
    create src\main\webapp\i18n\en\aEntity.json
  conflict src\main\webapp\i18n\en\global.json
 ? Overwrite src\main\webapp\i18n\en\global.json? overwrite
     force src\main\webapp\i18n\en\global.json
    create src\main\webapp\i18n\ja\aEntity.json
  conflict src\main\webapp\i18n\ja\global.json
 ? Overwrite src\main\webapp\i18n\ja\global.json? overwrite
     force src\main\webapp\i18n\ja\global.json 
 
 Running `webpack:build` to update client app
 
 Entity AEntity generated successfully.

1つのエンティティ追加だけで、これだけのファイルが修正されるのだね。


** 画面上でなにが変わるのか。 [#w5e51b5b]
えーっとですね。まずユーザで、ログインしてみたところ、メニューに、「エンティティ」のドロップダウンが追加されてました。

リストにダミーデータが入っている!

** JDLで書いたコメントはどうなったのだろうか。 [#q9d97d70]

上記のサンプルのjdlに、記入したコメントは、生成に反映されるのか確認

AEntityCommentは、どこに消えた?...

どこにも、反映されてないもよう。

AEntityNameCommentは、どこに消えた?...

これも、反映されてないもよう。

実験の結果、jdlのコメントは、生成時に、ないものとして、処理されてから、生成されていることがわかりました。

** 実験2 エンティティのカラムを1つ追加したらどうなるのか? [#ca0c891c]

例えば、エンティティにメールアドレスを追加しとしたら、どうなるのでしょう。

 entity AEntity {
 	aEntityName String
        aMailAddress String
 }
でやってみます。

 jhipster import-jdl jhipster-jdl.jh

*** 結果 [#ldb41b26]

 Found the .jhipster/AEntity.json configuration file, entity can be automatically generated!
 
 
 The entity AEntity is being updated.
 
      info Using blueprint generator-jhipster-vuejs for entity-client subgenerator
    create src\main\resources\config\liquibase\changelog\20190719014642_added_entity_AEntity.xml
  conflict src\main\resources\config\liquibase\data\a_entity.csv
 ? Overwrite src\main\resources\config\liquibase\data\a_entity.csv? overwrite
     force src\main\resources\config\liquibase\data\a_entity.csv
  conflict src\main\java\com\mycompany\myapp\domain\AEntity.java
 ? Overwrite src\main\java\com\mycompany\myapp\domain\AEntity.java? overwrite
     force src\main\java\com\mycompany\myapp\domain\AEntity.java
 identical src\main\java\com\mycompany\myapp\repository\AEntityRepository.java
 identical src\main\java\com\mycompany\myapp\web\rest\AEntityResource.java
  conflict src\test\java\com\mycompany\myapp\web\rest\AEntityResourceIT.java
 ? Overwrite src\test\java\com\mycompany\myapp\web\rest\AEntityResourceIT.java? overwrite
     force src\test\java\com\mycompany\myapp\web\rest\AEntityResourceIT.java
  conflict src\main\resources\config\liquibase\master.xml
 ? Overwrite src\main\resources\config\liquibase\master.xml? overwrite
     force src\main\resources\config\liquibase\master.xml
 identical src\main\java\com\mycompany\myapp\config\CacheConfiguration.java
  conflict src\main\webapp\app\entities\a-entity\a-entity-details.vue
 ? Overwrite src\main\webapp\app\entities\a-entity\a-entity-details.vue? overwrite
     force src\main\webapp\app\entities\a-entity\a-entity-details.vue
  conflict src\main\webapp\app\entities\a-entity\a-entity-update.vue
 ? Overwrite src\main\webapp\app\entities\a-entity\a-entity-update.vue? overwrite
     force src\main\webapp\app\entities\a-entity\a-entity-update.vue
  conflict src\main\webapp\app\entities\a-entity\a-entity.vue
 ? Overwrite src\main\webapp\app\entities\a-entity\a-entity.vue? overwrite
     force src\main\webapp\app\entities\a-entity\a-entity.vue
 identical src\main\webapp\app\core\jhi-navbar\jhi-navbar.vue
 identical src\main\webapp\app\entities\a-entity\a-entity-details.component.ts
  conflict src\main\webapp\app\entities\a-entity\a-entity-update.component.ts
 ? Overwrite src\main\webapp\app\entities\a-entity\a-entity-update.component.ts? overwrite
     force src\main\webapp\app\entities\a-entity\a-entity-update.component.ts
 identical src\main\webapp\app\entities\a-entity\a-entity.component.ts
 identical src\main\webapp\app\entities\a-entity\a-entity.service.ts
  conflict src\main\webapp\app\shared\model\a-entity.model.ts
 ? Overwrite src\main\webapp\app\shared\model\a-entity.model.ts? overwrite
     force src\main\webapp\app\shared\model\a-entity.model.ts
 identical src\test\javascript\spec\app\entities\a-entity\a-entity.component.spec.ts
 identical src\test\javascript\spec\app\entities\a-entity\a-entity-detail.component.spec.ts
 identical src\test\javascript\spec\app\entities\a-entity\a-entity-update.component.spec.ts
  conflict src\test\javascript\spec\app\entities\a-entity\a-entity.service.spec.ts
 ? Overwrite src\test\javascript\spec\app\entities\a-entity\a-entity.service.spec.ts? overwrite
     force src\test\javascript\spec\app\entities\a-entity\a-entity.service.spec.ts
 identical src\main\webapp\app\router\index.ts
 identical src\main\webapp\app\main.ts
  conflict src\main\webapp\i18n\en\aEntity.json
 ? Overwrite src\main\webapp\i18n\en\aEntity.json? overwrite
     force src\main\webapp\i18n\en\aEntity.json
 identical src\main\webapp\i18n\en\global.json
  conflict src\main\webapp\i18n\ja\aEntity.json
 ? Overwrite src\main\webapp\i18n\ja\aEntity.json? overwrite
     force src\main\webapp\i18n\ja\aEntity.json
 identical src\main\webapp\i18n\ja\global.json
 
 Running `webpack:build` to update client app
 
 Entity AEntity generated successfully.

で、気になるエラーが

 liquibase.exception.ValidationFailedException: Validation Failed:
      1 change sets check sum
           
 config/liquibase/changelog/20190719011806_added_entity_AEntity.xml::20190719011806-1-data::jhipster was: 8:a3c3a4caf7a78df32f18798fc9eb3fb7 but is now: 8:e7433bda47ea85d0868d7996ab6aeb15

*** ログファイルのありか [#ua9ab501]
 config/liquibase/changelog


*** 画面で確認すると、次のエラーが [#z56c967a]

 Caused by: org.h2.jdbc.JdbcSQLSyntaxErrorException: 列 "A_MAIL_ADDRESS" が見つかりません

カラムが更新されていないようだ。カラム追加には、何か、作法があるのだろう。

ググると、liquibaseチェックサムが働いて、勝手に変更できないようになってるみたい。
mavenの場合は、
 mvn liquibase:clearCheckSums
ってやらないと、叱られちゃうみたい。

gradleの場合は、

 ./gradlew liquibaseClearChecksums --stacktrace

なんだけど、

Caused by: org.gradle.internal.resolve.ModuleVersionNotFoundException: Could not find mysql:mysql-connector-java:.

って怒られた

** もしかして、 エンティティのカラム追加にコマンドあるんじゃないか説 [#p098aec4]
 jhipster entity 変更したいエンティティ
で、追加メニューがあることを確認しました。

トップ   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS