JHIPSTER一覧

目次

JHipsterドメイン言語(JDL)

JDLの概要

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

このページの原文(英語)

https://www.jhipster.tech/jdl/

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

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

JDL Studio

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

プレビュー機能

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サンプル

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

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

どうやって使うのですか

JDLファイルのインポート

その後、JDLファイルを使用してエンティティを生成できます。

実際に使えるやつ

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

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

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

でファイルを作成してダウンロードします。

チームで作業している場合は、おそらく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

あなたがあなたのプロジェクトでそれを使いたいならば、あなたはそうすることによってそうすることを加えることができます:

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

JDLファイルへのエクスポート

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

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

言語

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

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

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

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

アプリケーション宣言

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

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

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

application {
  config {}
}

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

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

これらのアプリケーションとフォルダを生成すると、いくつかのことが起こります。

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

エンティティ宣言

エンティティ宣言は次のように行われます。

entity <entity name> {
  <field name> <type> [<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フィールドを追加しているので、心配する必要はありません。

関係宣言

関係の宣言は次のように行われます。

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

これは簡単な例です:

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名前ではなく、ユーザに示すことができるように、フロントエンドに連結されたエンティティのを。

列挙型

JDLを使ってEnumを作るには、次のようにします。

 enum Language {
   FRENCH, ENGLISH, SPANISH
 }
 entity Book {
   title String required,
   description String,
   language Language
 }

ブロブ(byte [])

JHipsterは、イメージタイプと任意のバイナリタイプの間で選択できるので、素晴らしい選択をします。JDLを使えば同じことができます。エディタを使ってカスタムタイプ(DataType?を参照)を作成し、次の規約に従って名前を付けます。

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

オプション宣言

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ファイルを破損しないように無視します。

サービスオプション

指定されたサービスは、リポジトリインタフェースを直接呼び出すリソースクラスを作成しません。これはデフォルトで最も単純なオプションです。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

マイクロサービス関連のオプション

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番目のオプションはあなたのエンティティをどのようにそしてあなたが検索したいかを指定します。

アノテーション

注釈は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ファイルを使用する場合(マイクロサービスなど)には実際には便利です。

デプロイメント宣言

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

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

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

deployment {
  deploymentType docker-compose
  appsFolders [foo, bar]
  dockerRepositoryName "yourDockerLoginName"
}

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

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

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

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の名前にはコメントがありません。

すべての関係

JDLとの関係を作成する方法についての説明。

一対一

車に運転手がいて、運転手に車がある双方向の関係。

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
}

一対多

所有者に1つ以上のCarオブジェクトがなく、Carがその所有者を知っている双方向の関係。

entity Owner
entity Car
relationship OneToMany {
  Owner{car} to Car{owner}
}

この関係の単方向バージョンはJHipsterではサポートされていませんが、次のようになります。

entity Owner
entity Car
relationship OneToMany {
  Owner to Car
}

多対一

一対多の関係の相互バージョンは、以前と同じです。車がその所有者を知っている単方向バージョン:

entity Owner
entity Car
relationship ManyToOne {
  Car to Owner
}

多対多

最後に、この例では、ドライバを知っているCarがあり、Driverオブジェクトはそのcarにアクセスできます。

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

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

定数

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)
}

ワークフロー

モノリスワークフロー

ここに特別なワークフローはありません。

マイクロサービスのワークフロー

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

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

entity A
entity B
entity C

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

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

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

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

entity A
entity B
entity C 

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

これが結果です。

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

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

を参照してください。

附属書

利用可能なアプリケーションオプション

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? 本当の

	

利用可能な展開オプション

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の場合にのみ適用されます。

利用可能なフィールドタイプと制約

JDLでサポートされている型は次のとおりです。

共通データベース

共通データベースカサンドラ検証

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

利用可能なオプション

単項オプション

これらのオプションには意味がありません。

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

バイナリーオプション

これらのオプションは値を取ります。

トラブルシューティング

JDLインポートは、MS baseNameと一致するときに1つのエンティティーのみを検出します

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

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

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

を参照してください。

問題とバグ

JDLはGitHub?

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

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

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

に従っています。

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

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

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

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

翻訳者注:さいごに

このページは、だれでも、編集可能にしてあります。

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

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

練習してみる

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

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

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

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

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

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

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

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

gradlew clean 
jshipster import-jdl さっきダウンロードしたファイル名

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

1個のエンティティ作成の結果はこんな感じ

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つのエンティティ追加だけで、これだけのファイルが修正されるのだね。

画面上でなにが変わるのか。

えーっとですね。まずユーザで、ログインしてみたところ、メニューに、「エンティティ」のドロップダウンが追加されてました。

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

JDLで書いたコメントはどうなったのだろうか。

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

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

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

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

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

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

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

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

entity AEntity {
	aEntityName String
       aMailAddress String
}

でやってみます。

jhipster import-jdl jhipster-jdl.jh

結果

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

ログファイルのありか

config/liquibase/changelog

画面で確認すると、次のエラーが

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:.

って怒られた

もしかして、 エンティティのカラム追加にコマンドあるんじゃないか説

jhipster entity 変更したいエンティティ

で、追加メニューがあることを確認しました。

修正したいエンティティが、今回たまたま、 AEntityだったとすると

jhipster entity AEntity

と書きます。

すると、次のコマンドラインの質問がきます。

The entity AEntity is being updated.

? Do you want to update the entity? This will replace the existing files for this entity, all your custom code will be o

verwritten (Use arrow keys)

> Yes, re generate the entity
  Yes, add more fields and relationships
  Yes, remove fields and relationships
  No, exit

カーソルキーの上下で、選びます。

でも、このやり方も、一度、ダミーデータがはいってしまうと、データベースの変更チェックがはたらいてしまいました。

どうやって、回避するの?

いまのところ、うまくいくのは、

gradle clean

というありがちな方法でした。さいしょっから、やっておけばよかった。

トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2019-07-19 (金) 15:27:28 (125d)