Merge pull request #671 from progress0407/docs/faq-differ-kotlin-jdsl…

…-and-jooq-querydsl

docs: write (how Kotlin JDSL is different from jOOq and QueryDSL) FAQ document

docs/en/faq/how-can-i-see-the-generated-query.md

@@ -4,7 +4,7 @@ Kotlin JDSL prints queries and parameters generated by DSL to the debug log. So
 
 Because the parameters contained in the log are printed through the `toString` function, it can be difficult to identify the values unless `toString` function is overridden.
 
-```
+```kotlin
 select(
     path(Book::isbn),
 ).from(

docs/en/faq/how-kotlin-jdsl-is-different-from-jooq-and-querydsl.md

@@ -0,0 +1,35 @@
+# How is Kotlin JDSL different from jOOQ and QueryDSL?
+
+Unlike jOOQ and QueryDSL, Kotlin JDSL does not generate a `Metadata Model (code generation) for writing queries.
+
+There are several disadvantages to using the code generation approach
+
+1. increases project initial setup complexity
+2. adds metadata generation to the normal build process
+
+While the first drawback can be overcome with a number of plugins and references, the second is not.
+
+Code generation requires extra work between `modify entity` and `write query`, which breaks the developer's flow of thought.
+
+```
+1. Modify tables and entities
+2. Entity modification causes compile errors
+3. Run Maven or Gradle task to regenerate the metadata model
+4. Write query based on modified entity
+```
+
+Then you might think about trying JPQL yourself, but that might not be a good idea.
+
+JPQL uses a string-based way of writing queries, which makes it impossible to detect errors at compile time.
+
+For example, if you change a specific field in an entity, the JPQL string query that uses that field is not automatically corrected.
+
+Although the error can be resolved with the help of the IDE, it ends up being handled manually by the developer, which is a productivity killer.
+
+However, the Kotlin JDSL uses code generation and pure code-based query construction rather than string-based construction.
+
+This means that as soon as you modify an entity or field name, it is reflected in the query code, and the above inconvenience does not exist.
+
+It also adopts an ORM-based, object-oriented query approach like JPQL, which supports specifications such as polymorphism and fetch joins.
+
+Therefore, the way we write queries also relies on object names and fields to query, rather than querying the table/column itself.

docs/ko/faq/how-can-i-see-the-generated-query.md

@@ -4,7 +4,7 @@ Kotlin JDSL은 DSL를 통해 생성된 쿼리 및 파라미터를 debug 로그
 
 로그에 포함된 파라미터의 경우 `toString` 함수로 출력되기 때문에 만약 `toString` 함수가 오버라이드 되지 않았다면 식별에 어려움이 있을 수 있습니다.
 
-```
+```kotlin
 select(
     path(Book::isbn),
 ).from(

docs/ko/faq/how-kotlin-jdsl-is-different-from-jooq-and-querydsl.md

@@ -0,0 +1,37 @@
+# Kotlin JDSL은 jOOQ, QueryDSL와 무엇이 다른가요?
+
+jOOQ와 QueryDSL과 다르게 Kotlin JDSL의 경우 쿼리 작성을 위해 `메타 모델(Metadata Model)`을 생성하지 않습니다.
+
+메타 모델을 생성하기 위해서는 일반적으로 코드 제너레이션 방식을 사용하게 되고 이는 몇 가지 단점을 가지고 있습니다.
+
+
+1. 프로젝트 초기 설정 복잡도 증가
+2. 통상적인 빌드 프로세스 과정에 메타데이타터 생성 과정 추가
+
+1번은 여러 플러그인들과 레퍼런스들로 단점을 해소할 수 있지만 2번은 그렇지 않습니다.
+
+코드 제너레이션 방식을 사용할 경우 다음과 같이 `엔티티 수정`과 `쿼리 작성` 사이에 추가 작업이 요구되고 이는 개발자의 생각의 흐름을 끊어지게 만듭니다.
+
+```
+1. 테이블과 엔티티 수정
+2. 엔티티 수정으로 컴파일 오류 발생
+3. 메타데이터를 다시 생성하기 위해 Maven 또는 Gradle 작업 실행
+4. 수정된 엔티티를 기반으로 쿼리 작성
+```
+
+그러면 아마도 우리는 JPQL을 생각해볼 수도 있지만 이는 좋은 생각이 아닐 수 있습니다.
+
+JPQL은 문자열 기반의 쿼리 작성 방식을 사용하기 때문에, 컴파일 시점에 오류를 감지할 수 없습니다.
+
+예를 들어 엔티티의 특정 필드를 변경하더라도 해당 필드를 사용하는 JPQL 문자열 쿼리가 자동으로 수정되지 않습니다.
+
+비록 IDE의 도움을 받아 오류를 해결할 수 있지만 결국 개발자의 수작업으로 처리해야 하고 이는 생산성을 저하하는 요인이 됩니다.
+
+그러나 Kotlin JDSL은 코드 제너레이션 방식과 문자열 기반 작성이 아닌 순수한 코드 기반으로 쿼리를 작성합니다.
+
+즉, 엔티티나 필드 이름을 수정하는 즉시 쿼리 코드에 반영이 되어 위와 같은 불편함이 존재하지 않습니다.
+
+또한 JPQL과 같이 ORM 기반의 객체지향 쿼리를 채택하고 있어서 다형성, Fetch 조인 등의 스펙을 지원합니다.
+
+따라서 쿼리를 작성하는 방식 또한 테이블/컬럼 자체에 쿼리를 하는 것이 아닌 객체명과 필드에 의존하여 쿼리를 합니다.
+