Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

jdsl selectFrom function #776

Open
kihwankim opened this issue Oct 4, 2024 · 5 comments
Open

jdsl selectFrom function #776

kihwankim opened this issue Oct 4, 2024 · 5 comments
Assignees
Labels
enhancement New feature or request

Comments

@kihwankim
Copy link
Contributor

Backgrounds

  • queryDSL has selectFrom function and users migrating from QueryDSL to Kotlin-JDSL are forced to use the select() from() functions or develop an selectFrom extension function and use

Requirements

  • adding the 'selectFrom' function to the 'Jdsl' class makes it easier for people to use JDSL

Example

    authorRepository.findAll {
          selectFrom(
              entity(Author::class),
              leftJoin(BookAuthor::class).on(path(Author::authorId).equal(path(BookAuthor::authorId))),
          ).where(
              path(BookAuthor::authorId).isNull(),
          ).orderBy(
              path(Author::authorId).asc(),
          )
      }
@shouwn shouwn added the enhancement New feature or request label Oct 7, 2024
@shouwn
Copy link
Member

shouwn commented Oct 7, 2024

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.

@kihwankim
Copy link
Contributor Author

kihwankim commented Oct 7, 2024

@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을 올리게 되었습니다

@esperar
Copy link
Contributor

esperar commented Oct 31, 2024

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!

@shouwn
Copy link
Member

shouwn commented Nov 1, 2024

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

@shouwn
Copy link
Member

shouwn commented Nov 8, 2024

@esperar Sorry it took so long. I left a post on Discord to ask for feedback on this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants