Spring Boot environment in an XML file?
When I use the @-Query annotation and give the name of the query to the XML file that I put in the query mapping, it asks me for the result class, if it is possible that the written query does not return a specific result at all. I don't want to specify a result class for my query. do How is this done?
In the projects that I worked before, we could access the values of the queries in the xml file in this way. But it can't be done now. It probably has settings that I don't know. I have been researching and asking for a week, but I did not get any result and I am really confused. Please help me.
I'm not sure what exactly the goal is, but in a nutshell - you must specify some type for the result, this is how hibernate is designed and how java works. Java is not dynamic language, you can't just say "I don't want to specify result type". You must do it. You can specify something generic like "List<Object>" and then cast it. But again, this is not the idea of hibernate. You could better do it with raw jdbc (or JdbcTemplate), if you want to process results manually, column by column, do something unusual. But TBH, I don't see why you don't want to just define an pojo entity like Hiberanate wants, and use it as it's intended?
We used to do the same thing that I have shown in the photos in the company where I used to work. My guess is that a special configuration or an implementation for jpa has been written to write such queries. And this became an excuse to study more. After a lot of research that I did, it seems that a transformer class can be used to convert the results received from the query to the desired object. But I don't have any skills in this field and I don't know how to use it and is this method I guess correct?
Ah, ok, so you don't want to make it work the way how you described; you just want to learn how to do it properly, as designed. Is my understanding correct? If so, why not just google for some guides with examples. Here's for example first search result for "spring data named query separate file". https://attacomsian.com/blog/spring-data-jpa-named-queries And if you don't really need to use separate files for named queries, it's even better to not do it. The only benefit of defining queries in a separate file is to be able to modify those queries without rebuilding the app. Which is pretty rare use-case. So I highly recommend you to follow the simpler, less verbose approach. Like this https://docs.spring.io/spring-data/jpa/docs/current/reference/html/#jpa.query-methods.at-query public interface UserRepository extends JpaRepository<User, Long> { @Query("select u from User u where u.emailAddress = ?1") User findByEmailAddress(String emailAddress); } Just define it right in the code, along with the method. Having it in a separate file makes the code much harder to read, as the reader needs to navigate to a different file each time he'd like to glance over the query behind the java method. It will make your queries more error-prone, as it will be harder to notice mistakes both during code reviews, and during regular work with the codebase.
Thank you for your encouraging reply I have already read the article that was explained in the first link. This method requires that in addition to the name of the query, we also write the query in the method, which is not what I want. In our previous company, we used to do exactly what is shown in the photos that I sent earlier. I have already read the method explained in the second link, I have reviewed all the sites and documents. In the method in the second link, writing long queries and placing them in the repository layer makes the code ugly, and this is not the handwriting that I have learned in my company. We used to even define the version number of the project's dependencies in a separate file called gradle.properties of the queries, which are definitely more important than the versions of the dependencies. Maybe you are right and spending a week to solve this problem is not reasonable, but this will be an opportunity for me to gain more experience.
Having solid centralized version management mechanism makes HUGE sense. It's very helpful when all the versions are defined in one single place. Secondly, what's important for this discussion, - dependencies versions is something that will change frequently, and independently of the business logic. Usual reasons to upgrade dependencies - need new features in the framework, some vulnerability fix, support for something new, etc. In other words, versions of the dependencies you use are not a part of your BUSINESS REQUIREMENTS. They can be changed independently of business reuiqrements. In contrast, your queries are literally one of the most important pieces to fulfill the business requirements. In other words, your queries are very tightly coupled to business requirements. And there's no real reason to put them in a separately modifiable file. I mean, yeah, there is some advantage - in theory you can optimize some queries without rebuilding the application. But in any case, you won't be doing it outside of your normal process. And your normal process includes building and testing, i.e. generating new binary. So you won't win anything by having queries outside. Regarding readability. If you have long ugly query, it will remain ugly, but just in a different file. If the query is readable, it will be just placed in the same place where it's called. How this can become ugly??? @Query(""" delete from #{RefreshToken.TABLE} where #{RefreshToken.COLUMN_ID} = :id and #{RefreshToken.COLUMN_DEVICE_ID} = :deviceId returning * """) Mono<RefreshToken> deleteByIdAndDeviceId(@NotNull UUID id, @NotNull UUID deviceId);
Your answer is very logical and based on experience. Until now, I have not tried writing queries in the repository layer in the few lines you wrote. Now that I think about it, I see that your handwriting is also very interesting and makes it readable and can prevent confusion. Out of curiosity, I sought to find answers and gain experience. I sincerely thank you for patiently answering my question.
Yep, that was exactly *practical* recommendation, about how to better do it in growing codebases and when working in a team. But it's a good idea to learn all the approaches, to be aware of "plan B", in case if it suits the task. And I've realized that I didn't post you links to examples. Here's official documentation https://docs.spring.io/spring-data/jpa/docs/current/reference/html/#jpa.query-methods.named-queries.xml-named-query-definition https://memorynotfound.com/hibernate-jpa-named-query-xml-annotation-example/
Обсуждают сегодня