Open kihwankim opened 1 month ago
Hi @kihwankim. Thanks for the suggestion!
I'm hesitant to add the selectFrom function to Jdsl because it might lead to misunderstandings about the purpose of the library. Jdsl is designed to closely reflect the target language, and adding custom expressions might make users think we're abstracting that language too much. Ideally, users should have the freedom to create their own Custom DSLs that fit their personal style.
Also, Jdsl and QueryDSL have different approaches. In QueryDSL, you can chain methods after selectFrom to add joins, but this isn't possible in Jdsl. Using variable arguments in selectFrom seems to enforce a specific way of using it, which can be confusing. For example, it's unclear whether joins are included in what selectFrom returns just by looking at the method. This confusion arises because selectFrom is a unique construct of the library, not a standard method. This could lead us to respond to various user requests, such as supporting selectFrom().join() or allowing multiple where clauses, which can complicate decision-making.
However, if many users want selectFrom, I'm open to considering it, provided we have a clear vision for the future. Otherwise, the DSL might become too complex to enhance later on. I think it would be worth discussing further if this issue gets about 20 π, which is about 3% of our current stars.
@shouwn Thank you!
(It's a personal opinion, so if users need the selectFrom
function, please reply then)
I'm leaving a comment to appeal my opinion once again in case this issue gets a lot of π and becomes a subject of consideration.
Each individual may have a different style, but when calling the 'select' function about entity, the from
function often adds the same entity. And we developed a lot by adding fetchJoin if necessary.
since the select
from
function is repeated, people created and used a class that inherited the Jpql open class and add a selectFrom function or define it through an extended function to simplify logic.
In the process of repeated work, I thought it would be better if the Kotlin-JDSL Lib could provide that function, so I uploaded issue and PR
--- korean
κ°μ¬ν©λλ€! (κ°μΈμ μΈ μ견μ΄λ λ§μ μ¬μ©μλ€μ selectFrom ν¨μλ₯Ό νμλ‘ νλ©΄ κ·Έ λ λ΅κΈ λ¨κ²¨μ£ΌμΈμ!) λ€μ μ΄ issueκ° π λ₯Ό λ§μ΄ λ°μμ, κ³ λ € λμμ΄ λ κ²½μ°λ₯Ό μν΄μ μ μ μ견μ νλ² μ΄ν νκ³ μ λκΈμ λ¨κΉλλ€. κ° κ°μΈ λ§λ€ μ€νμΌ μ°¨μ΄κ° μκ² μ§λ§, entity λ¨μλ‘ select ν κ²½μ° fromλ λμΌν entityλ₯Ό λ£λκ²½μ°κ° λ§μ΅λλ€. κ·Έλ¦¬κ³ νμν κ²½μ° fetchJoinμ μΆκ°νλ λ°©μμΌλ‘ λ§μ΄ κ°λ°νμμ΅λλ€. μμ κ°μ μ½λκ° λ°λ³΅λλ€ λ³΄λ λ‘μ§μ κ°μν νκΈ° μν΄μ Jpql open class λ₯Ό μμλ°μμ selectFrom ν¨μλ₯Ό μΆκ°νκ±°λ , νμ₯ν¨μλ₯Ό ν΅ν΄μ μ μν΄μ μ¬μ©νλ κ²½μ°κ° λ§μ΄ λ°μνμμ΅λλ€. λ°λ³΅λ μμ κ³Όμ μμ jdsl lib λ¨μμ ν΄λΉ κΈ°λ₯μ μ 곡ν΄μ£Όλ©΄ μ’κ² λ€λ μκ°μ΄ λ§μ΄λ€μ΄μ issue μ PRμ μ¬λ¦¬κ² λμμ΅λλ€
This is a personal opinion!
I think itβs a reasonable decision to implement a feature once an issue receives 20 π reactions, especially from the perspective of managing open source projects.
However, I believe that even though Kotlin JDSL is not actively maintained as an open source project, it is used directly by a relatively larger number of people.
Iβm not sure if this matter has been brought up in the Discord community, but personally, I feel that information dissemination is somewhat lacking.
I think it would be good to spread the word more broadly about the requirement for 20 π reactions to check whether the feature will be implemented or not. Thank you!
@esperar As you said, it would be good to make an announcement on Discord or something, since this is a survey. Thank you for the good feedback.
I'll try to make an announcement on Discord sometime next week.
@esperar Sorry it took so long. I left a post on Discord to ask for feedback on this issue.
Backgrounds
queryDSL
has selectFrom function and users migrating from QueryDSL to Kotlin-JDSL are forced to use theselect()
from()
functions or develop anselectFrom
extension function and useRequirements
Example