I have been reading about Spring Boot custom repository. I have dozens of blogs explaining how to implement those but none of them explained scenario when we actually need it?
I mean one example where we cannot live without custom repo. I mean if there is case of complex query, we can anyhow achieve it using #Query.
Please explain.
Lets say I want strongly typed query instead of #Query. I would create a custom repo, autowire EntityManager and use QueryDSL with it so I can use strongly typed references.
You can use it to extend the repository with other libraries that aren't part of Spring.
I find them useful when working with a program generator like jHipster. They keep your code separate from the generated code.
The xxxRepositoryCustom.java xxxRepositoryImpl will not be overwritten when the entities are re-generated by a dumb programmer (me.) The queries themselves have some complex logic that can not be expressed in a simple #Query
Related
Not sure if this will be considered a "legitimate question" or "purely opinion based", but is there a "best practice" with regards to directly testing a repository in a Spring Boot application? Or, should any integration testing simply target the associated service?
The reasoning for the question is simply the fact that, for the most part, a repository in a Spring Boot application contains no project-generated code. At best, it contains project-defined method signatures which Spring generates implementations for (assuming correct naming conventions).
Thanks...
If you can mess it up, you should test it. Here the opportunities to mess up can include:
Custom Queries (using #Query) might be wrong (there can be all kinds of logic mistakes or typos writing a query with no compile-time checking)
Repository methods where the query is derived from the method name might not be what you intended.
Arguments passed in, the type on the parameter list might not match the type needed in the query (nothing enforces this at compile time).
In all these cases you're not testing Spring Data JPA, you're testing the functionality you are implementing using Spring Data JPA.
Cases of using provided methods out of the box, like findOne, findAll, save, etc., where your fingerprints are not on it, don't need testing.
It's easy to test this stuff, and better to find the bugs earlier than later.
Yes, I think is a good pratice to do that. You could use #DataJpaTest annotation, it starts a in memory database. The official documentation says:
You can use the #DataJpaTest annotation to test JPA applications. By default, it configures an in-memory embedded database, scans for #Entity classes, and configures Spring Data JPA repositories. Regular #Component beans are not loaded into the ApplicationContext.
Link to the docs: https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-testing.html
Starting from the idea that repositories should be used only inside services and services are used to interact with the other layers of the system, I would say that testing services should be enough in the majority of cases.
I would not test standard repository methods like findAll, or findBy.., they were tested already and the purpose is not to test JPA, but rather the application.
The only repository methods that should have direct tests are the ones with custom queries. These queries may be located in a shared library and it is not efficient to write similar tests across different projects(in this case regression is a big concern)
I used GWT2+DAO pattern for my apps and it's work correctly. Now my BD as grown a lot and i want to manage it more easier. So I want to use an ORM.What i want to do is to keep my first DAO implementation and use hibernate for my new classes. But I read a lot on internet and I'm very confused about the way to deal with this.
which solution between hibernate ejb3+Tomcat+Openejb and Spring+hibernate could be better for me?
also which one could be the fastest?
Should I change all my dao to use hibernate methods or should I use the both?
NB: I'm just started to read spring doc, but I have already read hibernate doc.
thanks.
I think the change you need only affects the back-end, hence has nothing to do with the server or container you are using.
Rather in your DAO, when saving new pojos, use hibernateTemplate instead of what you were using.
It would be advisable to actually be consistent, if you are going to use hibernate, use hibernate for all your db manipulation.
Optimization is a whole chapter on itself, I think you should focus on getting your db changes for now, then worry about the speed when everything works.
I read about the server extensions available in neo4j in server mode. I was wondering if it is possible to somehow annotate repository method to use this extension insted of allowing to create query based on method name or #Query annotation?
If not, is there easy way to invoke REST interface methods using Neo4jTemplate?
That's not possible right now, it would be cool though, feel free to raise a JIRA issue that describes your suggestion in more detail. Perhaps Spring-Data-REST Clients allow such a thing.
I want to add custom behavior to single repository as described in 1.4.1 Adding behaviour to single repositories. In this custom behavior I want to use method already present in my base repository (like save() or findOne() method). Ho can I achieve this in Spring data?
I tried extending my UserRepositoryImpl with SimpleJpaRepository to have basic SimpleJpaRepository methods available. But this way I got instantiation problems.
Also using aproach described in 1.4.2 Adding custom behaviour to all repositories doesn't seem like good solution, because it's way too much code for adding one simple method. In this case Spring Data seems more like burden.
Or is it antipatern to add to my repository such simple method which depends on other methods from base repository? Should I rather move this method to service/business layer?
The same question came up a few days ago in this post. As I wrote there as well, I strongly believe this is an antipattern, so my answer to your last question would be a definite yes.
So this is a rather "big" question, but what I'm trying to accomplish is the following:
I have a Spring application, MVC, JDBC (MySQL) and JSP running on tomcat.
My objective is to test the entire "stack" using a proper method.
What I have so far is Junit using Selenium to simulate an actual user interacting with the application (requires a dummy account for that), and performing different validations such as, see if element is present in the page, see if the database has a specific value or if a value matches the database.
1st concern is that this is actually using the database so it's hard to test certain scenarios. I would really like to be able to mock the database. Have it emulate specific account configs, data states etc
2nd concern is that given the fact that I use what is in the database, and data is continuously changing, it is hard to predict behavior, and therefore properly asserting
I looked at Spring Test but it allows for testing outside a servlet container, so no JSP and no Javascript testing possible.
I saw DBUtils documentation but not sure if it will help me in this case
So, to my fellow developers, I would like to ask for tips to:
Run selenium tests on top of a mocked database
Allow different configs per test
Keep compatibility with Maven/Gradle
I have started with an ordered autowire feature to support this kind of stubbing.
It's basically an idea that i took over from the Seam framework i was working with in the past but i couldnt find yet a similar thing in spring.
The idea is to have a precedence annotation (fw, app,mock,...) that will be used to resolve the current implementation of an autowired bean. This is easy already in xml but not with java config.
So we have our normal repository beans in with app precedence and a test package stubbing these classes with mock precedence.
If both are in the classpath spring would normally fail with a duplicate bean found exception. In our case the extended beanfactory simply takes the bean with the highest precedence.
Im not sure if the order annotation of spring could be used directly but i prefered to have "well defined" precedence scopes anyway, so it will be clear for our developers what this is about.
! While this is a nice approach to stub so beans for testing i would not use it to replace a database definition but rather go with an inmemory database like hsql, like some previous answers mentionned already. !