Custom delete method in JpaRepository
up vote
1
down vote
favorite
I'd like to know if there's a way of overriding the delete method for some of my JpaRepository's without having to override the rest of the methods.
Currently I have something like
public interface UserRepo extends JpaRepository<User, Long>
{
findUserById(long id);
findUserByEmail(String email);
// etc...
}
And I'd like to override the delete(T Entity)
method in CrudRepository
. To do so I've tried implementing the UserRepo
but then I have to implement all the findByX
and haven't really find anything around on how to properly do that.
Is there any annotation to add to a function in the Entity class so it runs when you call UserRepo.delete(myUser)
?
Thanks in advance!
spring spring-boot spring-data-jpa spring-data
add a comment |
up vote
1
down vote
favorite
I'd like to know if there's a way of overriding the delete method for some of my JpaRepository's without having to override the rest of the methods.
Currently I have something like
public interface UserRepo extends JpaRepository<User, Long>
{
findUserById(long id);
findUserByEmail(String email);
// etc...
}
And I'd like to override the delete(T Entity)
method in CrudRepository
. To do so I've tried implementing the UserRepo
but then I have to implement all the findByX
and haven't really find anything around on how to properly do that.
Is there any annotation to add to a function in the Entity class so it runs when you call UserRepo.delete(myUser)
?
Thanks in advance!
spring spring-boot spring-data-jpa spring-data
Please have a look into below issue somehow it related: stackoverflow.com/questions/39923434/…
– Raheela Aslam
Nov 8 at 10:53
Nope, that's not what I wanted to achieve.
– epsilonmajorquezero
Nov 8 at 11:12
add a comment |
up vote
1
down vote
favorite
up vote
1
down vote
favorite
I'd like to know if there's a way of overriding the delete method for some of my JpaRepository's without having to override the rest of the methods.
Currently I have something like
public interface UserRepo extends JpaRepository<User, Long>
{
findUserById(long id);
findUserByEmail(String email);
// etc...
}
And I'd like to override the delete(T Entity)
method in CrudRepository
. To do so I've tried implementing the UserRepo
but then I have to implement all the findByX
and haven't really find anything around on how to properly do that.
Is there any annotation to add to a function in the Entity class so it runs when you call UserRepo.delete(myUser)
?
Thanks in advance!
spring spring-boot spring-data-jpa spring-data
I'd like to know if there's a way of overriding the delete method for some of my JpaRepository's without having to override the rest of the methods.
Currently I have something like
public interface UserRepo extends JpaRepository<User, Long>
{
findUserById(long id);
findUserByEmail(String email);
// etc...
}
And I'd like to override the delete(T Entity)
method in CrudRepository
. To do so I've tried implementing the UserRepo
but then I have to implement all the findByX
and haven't really find anything around on how to properly do that.
Is there any annotation to add to a function in the Entity class so it runs when you call UserRepo.delete(myUser)
?
Thanks in advance!
spring spring-boot spring-data-jpa spring-data
spring spring-boot spring-data-jpa spring-data
asked Nov 8 at 10:49
epsilonmajorquezero
80111
80111
Please have a look into below issue somehow it related: stackoverflow.com/questions/39923434/…
– Raheela Aslam
Nov 8 at 10:53
Nope, that's not what I wanted to achieve.
– epsilonmajorquezero
Nov 8 at 11:12
add a comment |
Please have a look into below issue somehow it related: stackoverflow.com/questions/39923434/…
– Raheela Aslam
Nov 8 at 10:53
Nope, that's not what I wanted to achieve.
– epsilonmajorquezero
Nov 8 at 11:12
Please have a look into below issue somehow it related: stackoverflow.com/questions/39923434/…
– Raheela Aslam
Nov 8 at 10:53
Please have a look into below issue somehow it related: stackoverflow.com/questions/39923434/…
– Raheela Aslam
Nov 8 at 10:53
Nope, that's not what I wanted to achieve.
– epsilonmajorquezero
Nov 8 at 11:12
Nope, that's not what I wanted to achieve.
– epsilonmajorquezero
Nov 8 at 11:12
add a comment |
7 Answers
7
active
oldest
votes
up vote
1
down vote
accepted
Not sure I understand you clear enough, but lets try:
... I have to implement all the findByX ...
You don't, spring will generate JPQL snippet if you name methods in your interface with suitable convection please take a look at this and this articles
... Is there any annotation to add to a function in the Entity class
so it runs when you call UserRepo.delete(myUser)? ...
You can use @PreRemove
/ @PostRemove
annotation on method in your entity class:
@PreRemove / @PostRemove
public void someMethod() { ... }
Regarding the first one: If Iimplement
theUserRepo
then I have to implement all the methods I have there. So if I'm exposing afindByEmail
in theUserRepo
, then inUserRepoImpl
where I could override thedelete
I must code thefindByEmail
. Regarding the @PreRemove/@PostRemove, I saw those but they are acting onEntityManager.remove()
if I'm not mistaken. Will that work inUserRepo.delete(myUser)
?
– epsilonmajorquezero
Nov 8 at 11:08
Ok, it seems that @PreRemove/@PostRemove work with theUserRepo.delete(myUser)
. I though they acted for theremove
method on theEntityManager
. Is that being used behind the scenes by JpaRepository? Anywhere to read more about it? Much thanks!
– epsilonmajorquezero
Nov 8 at 13:08
Take a look at this article: baeldung.com/database-auditing-jpa
– Kamil W.
Nov 8 at 13:24
add a comment |
up vote
2
down vote
In addition to Raheela Aslam post:
Spring-data documentation has an example of how you can override standard repository methods, for example:
interface CustomizedSave<T> {
<S extends T> S save(S entity);
}
class CustomizedSaveImpl<T> implements CustomizedSave<T> {
public <S extends T> S save(S entity) {
// Your custom implementation
}
}
interface UserRepository extends CrudRepository<User, Long>, CustomizedSave<User> {
}
You can read about it there:
https://docs.spring.io/spring-data/jpa/docs/2.1.2.RELEASE/reference/html/#repositories.custom-implementations
UPD:
Read it carefully, because there are some important things, e.g
The most important part of the class name that corresponds to the fragment interface is the Impl postfix.
Also the documentation says:
Custom implementations have a higher priority than the base implementation and repository aspects.
Yeah, I saw that in the documentation but I really hoped there was an more simple way similar to the one proposed by @Kamil W. But I'll have to go that way if nothing better is possible :)
– epsilonmajorquezero
Nov 8 at 11:25
add a comment |
up vote
0
down vote
There are several ways to do this depending on what you're trying to do:
- Use method naming, and let Spring derive the JPQL query from the naming (https://www.petrikainulainen.net/programming/spring-framework/spring-data-jpa-tutorial-creating-database-queries-from-method-names/)
- Use the Query annotation and add the desired JPQL query in the annotation (https://www.petrikainulainen.net/programming/spring-framework/spring-data-jpa-tutorial-creating-database-queries-with-the-query-annotation/)
- Use a named query (https://www.petrikainulainen.net/programming/spring-framework/spring-data-jpa-tutorial-creating-database-queries-with-named-queries/)
I prefer to use method naming if possible, the method name gets long, but you know exactly what it does by looking at it.
The thing is that I really need to override the delete method and do some stuff in the code before the User gets deleted so just SQL stuff may not do the whole trick.
– epsilonmajorquezero
Nov 8 at 11:12
Then you should do that in the service layer, not in the repository.
– lgaleazzi
Nov 8 at 11:14
Then I'm afraid someone without much idea of what's happening will come and just callUserRepo.dele(myUser)
and mess up with the data in the DB.
– epsilonmajorquezero
Nov 8 at 11:22
Then I guess JpaRepositories are not working out for you. They are there for basic CRUD operations, definitely not to add business logic.
– lgaleazzi
Nov 8 at 11:33
add a comment |
up vote
0
down vote
In your case code will be like as below:
public interface UserRepo extends JpaRepository<User, Long>
{
findUserById(long id);
findUserByEmail(String email);
// etc...
}
public interface UserRepositoryCustom {
void deleteByEmail(String email);
}
public interface UserRepositoryImpl implements UserRepositoryCustom {
public void deleteByEmail(String email) {
//provide your custom implimentation
}
}
Yeah, I know I can do that but is thedelete(T entity)
that I want to override to prevent an unaware developer from calling it instead of thedeleteByEmail
with custom behaviour and messing stuff becausedelete
is not doing what it should but still deleting the Entity in the data base.
– epsilonmajorquezero
Nov 8 at 11:03
Ok Then you can create you custom Repository interface and then provide custom implementation.
– Raheela Aslam
Nov 8 at 11:07
That's what I also commented on the post. If I provide a custom implementation then I have to implement all thefindByX
methodfs too which is quite a bit of extra work and me messing with SQL more than I'd like too in that case :)
– epsilonmajorquezero
Nov 8 at 11:10
1
No you have to create UserRepository and UserRepositoryCustom in custom you can add methods that you want to provide custom implementation.
– Raheela Aslam
Nov 8 at 11:13
Ok, now I understand what you emant and yeah, I know this approach is possible but hoped for something nicer to exist. I'll end up doing that if there's nothing better.
– epsilonmajorquezero
Nov 8 at 11:27
add a comment |
up vote
0
down vote
If you want to keep Spring's behavior for deletion, but want to have some logic to be executed either before or after, you may utilize java8's interface default methods, and try the following :
public interface UserRepo extends JpaRepository<User, Long> {
default void customDelete(User user) {
// before logic
// ..
delete(user); // actual call to deletion
// after logic
// ..
}
}
Nope, that wouldn't prefent an unaware coder from calling regular delete by mistake. And you can't write code in an interface, can you?
– epsilonmajorquezero
Nov 8 at 12:00
From java 8 onwards, yes you can. Look at docs for more info docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html
– Elg
Nov 8 at 12:05
add a comment |
up vote
0
down vote
Hi you can write your own Interface write implementation with EntityManager and
extend in you interface here is the sample :
- https://dzone.com/articles/accessing-the-entitymanager-from-spring-data-jpa
Actually one more way is writing by soemthing like :
User findByUsername(String username) // it will find the user by specific username
spring data will create you an implementation of this method
The same way you can create your own delete method
Here is useful links:
https://docs.spring.io/spring-data/jpa/docs/current/reference/html/#repositories.custom-implementations
In this link you can go to part 2.3 QueryMethods:
- https://docs.spring.io/spring-data/jpa/docs/1.6.0.RELEASE/reference/html/jpa.repositories.html
You can also define @NameQuery in your entity class:
@Entity
@Table(name = "employee", schema="spring_data_jpa_example")
@NamedQuery(name = "Employee.yourMethodQueryName",
query = "yourQuery"
)
public class Employee {}
@Repository
public interface EmployeeRepository extends JpaRepository<Employee,Long> {
List<Employee> yourMethodQueryName(Your list of params);
}
Here is link with sample:
- https://www.logicbig.com/tutorials/spring-framework/spring-data/jpa-named-queries.html
I think this is helpful for you
I expected something a bit nicer (like calling some code in the Entity itself) than the custom repo for delete but I'll endup doing that if necessary :)
– epsilonmajorquezero
Nov 8 at 11:29
Updated answer you can look)
– Mykhailo Moskura
Nov 8 at 11:55
Thanks, but what I actually want is to call some code on the soonToBeDeleted entity and then delete it, not just SQL :)
– epsilonmajorquezero
Nov 8 at 12:02
add a comment |
up vote
0
down vote
public interface UserRepo extends JpaRepository<User, Long> {
@Modifying
@Query("delete from User u where u.email = ?1")
void deleteByEmail(String email);
}
That wouldn't override thedelete
method which is what (I think) I need to do :)
– epsilonmajorquezero
Nov 8 at 11:05
While this code snippet may solve the problem, it doesn't explain why or how it answers the question. Please include an explanation for your code, as that really helps to improve the quality of your post. Remember that you are answering the question for readers in the future, and those people might not know the reasons for your code suggestion.
– Luca Kiebel
Nov 8 at 12:27
This does not provide an answer to the question. Once you have sufficient reputation you will be able to comment on any post; instead, provide answers that don't require clarification from the asker. - From Review
– Harsh
Nov 8 at 18:00
stackoverflow.com/questions/43665090/…
– Faisal Mk
Nov 9 at 5:05
add a comment |
7 Answers
7
active
oldest
votes
7 Answers
7
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
accepted
Not sure I understand you clear enough, but lets try:
... I have to implement all the findByX ...
You don't, spring will generate JPQL snippet if you name methods in your interface with suitable convection please take a look at this and this articles
... Is there any annotation to add to a function in the Entity class
so it runs when you call UserRepo.delete(myUser)? ...
You can use @PreRemove
/ @PostRemove
annotation on method in your entity class:
@PreRemove / @PostRemove
public void someMethod() { ... }
Regarding the first one: If Iimplement
theUserRepo
then I have to implement all the methods I have there. So if I'm exposing afindByEmail
in theUserRepo
, then inUserRepoImpl
where I could override thedelete
I must code thefindByEmail
. Regarding the @PreRemove/@PostRemove, I saw those but they are acting onEntityManager.remove()
if I'm not mistaken. Will that work inUserRepo.delete(myUser)
?
– epsilonmajorquezero
Nov 8 at 11:08
Ok, it seems that @PreRemove/@PostRemove work with theUserRepo.delete(myUser)
. I though they acted for theremove
method on theEntityManager
. Is that being used behind the scenes by JpaRepository? Anywhere to read more about it? Much thanks!
– epsilonmajorquezero
Nov 8 at 13:08
Take a look at this article: baeldung.com/database-auditing-jpa
– Kamil W.
Nov 8 at 13:24
add a comment |
up vote
1
down vote
accepted
Not sure I understand you clear enough, but lets try:
... I have to implement all the findByX ...
You don't, spring will generate JPQL snippet if you name methods in your interface with suitable convection please take a look at this and this articles
... Is there any annotation to add to a function in the Entity class
so it runs when you call UserRepo.delete(myUser)? ...
You can use @PreRemove
/ @PostRemove
annotation on method in your entity class:
@PreRemove / @PostRemove
public void someMethod() { ... }
Regarding the first one: If Iimplement
theUserRepo
then I have to implement all the methods I have there. So if I'm exposing afindByEmail
in theUserRepo
, then inUserRepoImpl
where I could override thedelete
I must code thefindByEmail
. Regarding the @PreRemove/@PostRemove, I saw those but they are acting onEntityManager.remove()
if I'm not mistaken. Will that work inUserRepo.delete(myUser)
?
– epsilonmajorquezero
Nov 8 at 11:08
Ok, it seems that @PreRemove/@PostRemove work with theUserRepo.delete(myUser)
. I though they acted for theremove
method on theEntityManager
. Is that being used behind the scenes by JpaRepository? Anywhere to read more about it? Much thanks!
– epsilonmajorquezero
Nov 8 at 13:08
Take a look at this article: baeldung.com/database-auditing-jpa
– Kamil W.
Nov 8 at 13:24
add a comment |
up vote
1
down vote
accepted
up vote
1
down vote
accepted
Not sure I understand you clear enough, but lets try:
... I have to implement all the findByX ...
You don't, spring will generate JPQL snippet if you name methods in your interface with suitable convection please take a look at this and this articles
... Is there any annotation to add to a function in the Entity class
so it runs when you call UserRepo.delete(myUser)? ...
You can use @PreRemove
/ @PostRemove
annotation on method in your entity class:
@PreRemove / @PostRemove
public void someMethod() { ... }
Not sure I understand you clear enough, but lets try:
... I have to implement all the findByX ...
You don't, spring will generate JPQL snippet if you name methods in your interface with suitable convection please take a look at this and this articles
... Is there any annotation to add to a function in the Entity class
so it runs when you call UserRepo.delete(myUser)? ...
You can use @PreRemove
/ @PostRemove
annotation on method in your entity class:
@PreRemove / @PostRemove
public void someMethod() { ... }
answered Nov 8 at 11:01
Kamil W.
506216
506216
Regarding the first one: If Iimplement
theUserRepo
then I have to implement all the methods I have there. So if I'm exposing afindByEmail
in theUserRepo
, then inUserRepoImpl
where I could override thedelete
I must code thefindByEmail
. Regarding the @PreRemove/@PostRemove, I saw those but they are acting onEntityManager.remove()
if I'm not mistaken. Will that work inUserRepo.delete(myUser)
?
– epsilonmajorquezero
Nov 8 at 11:08
Ok, it seems that @PreRemove/@PostRemove work with theUserRepo.delete(myUser)
. I though they acted for theremove
method on theEntityManager
. Is that being used behind the scenes by JpaRepository? Anywhere to read more about it? Much thanks!
– epsilonmajorquezero
Nov 8 at 13:08
Take a look at this article: baeldung.com/database-auditing-jpa
– Kamil W.
Nov 8 at 13:24
add a comment |
Regarding the first one: If Iimplement
theUserRepo
then I have to implement all the methods I have there. So if I'm exposing afindByEmail
in theUserRepo
, then inUserRepoImpl
where I could override thedelete
I must code thefindByEmail
. Regarding the @PreRemove/@PostRemove, I saw those but they are acting onEntityManager.remove()
if I'm not mistaken. Will that work inUserRepo.delete(myUser)
?
– epsilonmajorquezero
Nov 8 at 11:08
Ok, it seems that @PreRemove/@PostRemove work with theUserRepo.delete(myUser)
. I though they acted for theremove
method on theEntityManager
. Is that being used behind the scenes by JpaRepository? Anywhere to read more about it? Much thanks!
– epsilonmajorquezero
Nov 8 at 13:08
Take a look at this article: baeldung.com/database-auditing-jpa
– Kamil W.
Nov 8 at 13:24
Regarding the first one: If I
implement
the UserRepo
then I have to implement all the methods I have there. So if I'm exposing a findByEmail
in the UserRepo
, then in UserRepoImpl
where I could override the delete
I must code the findByEmail
. Regarding the @PreRemove/@PostRemove, I saw those but they are acting on EntityManager.remove()
if I'm not mistaken. Will that work in UserRepo.delete(myUser)
?– epsilonmajorquezero
Nov 8 at 11:08
Regarding the first one: If I
implement
the UserRepo
then I have to implement all the methods I have there. So if I'm exposing a findByEmail
in the UserRepo
, then in UserRepoImpl
where I could override the delete
I must code the findByEmail
. Regarding the @PreRemove/@PostRemove, I saw those but they are acting on EntityManager.remove()
if I'm not mistaken. Will that work in UserRepo.delete(myUser)
?– epsilonmajorquezero
Nov 8 at 11:08
Ok, it seems that @PreRemove/@PostRemove work with the
UserRepo.delete(myUser)
. I though they acted for the remove
method on the EntityManager
. Is that being used behind the scenes by JpaRepository? Anywhere to read more about it? Much thanks!– epsilonmajorquezero
Nov 8 at 13:08
Ok, it seems that @PreRemove/@PostRemove work with the
UserRepo.delete(myUser)
. I though they acted for the remove
method on the EntityManager
. Is that being used behind the scenes by JpaRepository? Anywhere to read more about it? Much thanks!– epsilonmajorquezero
Nov 8 at 13:08
Take a look at this article: baeldung.com/database-auditing-jpa
– Kamil W.
Nov 8 at 13:24
Take a look at this article: baeldung.com/database-auditing-jpa
– Kamil W.
Nov 8 at 13:24
add a comment |
up vote
2
down vote
In addition to Raheela Aslam post:
Spring-data documentation has an example of how you can override standard repository methods, for example:
interface CustomizedSave<T> {
<S extends T> S save(S entity);
}
class CustomizedSaveImpl<T> implements CustomizedSave<T> {
public <S extends T> S save(S entity) {
// Your custom implementation
}
}
interface UserRepository extends CrudRepository<User, Long>, CustomizedSave<User> {
}
You can read about it there:
https://docs.spring.io/spring-data/jpa/docs/2.1.2.RELEASE/reference/html/#repositories.custom-implementations
UPD:
Read it carefully, because there are some important things, e.g
The most important part of the class name that corresponds to the fragment interface is the Impl postfix.
Also the documentation says:
Custom implementations have a higher priority than the base implementation and repository aspects.
Yeah, I saw that in the documentation but I really hoped there was an more simple way similar to the one proposed by @Kamil W. But I'll have to go that way if nothing better is possible :)
– epsilonmajorquezero
Nov 8 at 11:25
add a comment |
up vote
2
down vote
In addition to Raheela Aslam post:
Spring-data documentation has an example of how you can override standard repository methods, for example:
interface CustomizedSave<T> {
<S extends T> S save(S entity);
}
class CustomizedSaveImpl<T> implements CustomizedSave<T> {
public <S extends T> S save(S entity) {
// Your custom implementation
}
}
interface UserRepository extends CrudRepository<User, Long>, CustomizedSave<User> {
}
You can read about it there:
https://docs.spring.io/spring-data/jpa/docs/2.1.2.RELEASE/reference/html/#repositories.custom-implementations
UPD:
Read it carefully, because there are some important things, e.g
The most important part of the class name that corresponds to the fragment interface is the Impl postfix.
Also the documentation says:
Custom implementations have a higher priority than the base implementation and repository aspects.
Yeah, I saw that in the documentation but I really hoped there was an more simple way similar to the one proposed by @Kamil W. But I'll have to go that way if nothing better is possible :)
– epsilonmajorquezero
Nov 8 at 11:25
add a comment |
up vote
2
down vote
up vote
2
down vote
In addition to Raheela Aslam post:
Spring-data documentation has an example of how you can override standard repository methods, for example:
interface CustomizedSave<T> {
<S extends T> S save(S entity);
}
class CustomizedSaveImpl<T> implements CustomizedSave<T> {
public <S extends T> S save(S entity) {
// Your custom implementation
}
}
interface UserRepository extends CrudRepository<User, Long>, CustomizedSave<User> {
}
You can read about it there:
https://docs.spring.io/spring-data/jpa/docs/2.1.2.RELEASE/reference/html/#repositories.custom-implementations
UPD:
Read it carefully, because there are some important things, e.g
The most important part of the class name that corresponds to the fragment interface is the Impl postfix.
Also the documentation says:
Custom implementations have a higher priority than the base implementation and repository aspects.
In addition to Raheela Aslam post:
Spring-data documentation has an example of how you can override standard repository methods, for example:
interface CustomizedSave<T> {
<S extends T> S save(S entity);
}
class CustomizedSaveImpl<T> implements CustomizedSave<T> {
public <S extends T> S save(S entity) {
// Your custom implementation
}
}
interface UserRepository extends CrudRepository<User, Long>, CustomizedSave<User> {
}
You can read about it there:
https://docs.spring.io/spring-data/jpa/docs/2.1.2.RELEASE/reference/html/#repositories.custom-implementations
UPD:
Read it carefully, because there are some important things, e.g
The most important part of the class name that corresponds to the fragment interface is the Impl postfix.
Also the documentation says:
Custom implementations have a higher priority than the base implementation and repository aspects.
edited Nov 8 at 11:22
answered Nov 8 at 11:14
Aleksandr Semyannikov
206111
206111
Yeah, I saw that in the documentation but I really hoped there was an more simple way similar to the one proposed by @Kamil W. But I'll have to go that way if nothing better is possible :)
– epsilonmajorquezero
Nov 8 at 11:25
add a comment |
Yeah, I saw that in the documentation but I really hoped there was an more simple way similar to the one proposed by @Kamil W. But I'll have to go that way if nothing better is possible :)
– epsilonmajorquezero
Nov 8 at 11:25
Yeah, I saw that in the documentation but I really hoped there was an more simple way similar to the one proposed by @Kamil W. But I'll have to go that way if nothing better is possible :)
– epsilonmajorquezero
Nov 8 at 11:25
Yeah, I saw that in the documentation but I really hoped there was an more simple way similar to the one proposed by @Kamil W. But I'll have to go that way if nothing better is possible :)
– epsilonmajorquezero
Nov 8 at 11:25
add a comment |
up vote
0
down vote
There are several ways to do this depending on what you're trying to do:
- Use method naming, and let Spring derive the JPQL query from the naming (https://www.petrikainulainen.net/programming/spring-framework/spring-data-jpa-tutorial-creating-database-queries-from-method-names/)
- Use the Query annotation and add the desired JPQL query in the annotation (https://www.petrikainulainen.net/programming/spring-framework/spring-data-jpa-tutorial-creating-database-queries-with-the-query-annotation/)
- Use a named query (https://www.petrikainulainen.net/programming/spring-framework/spring-data-jpa-tutorial-creating-database-queries-with-named-queries/)
I prefer to use method naming if possible, the method name gets long, but you know exactly what it does by looking at it.
The thing is that I really need to override the delete method and do some stuff in the code before the User gets deleted so just SQL stuff may not do the whole trick.
– epsilonmajorquezero
Nov 8 at 11:12
Then you should do that in the service layer, not in the repository.
– lgaleazzi
Nov 8 at 11:14
Then I'm afraid someone without much idea of what's happening will come and just callUserRepo.dele(myUser)
and mess up with the data in the DB.
– epsilonmajorquezero
Nov 8 at 11:22
Then I guess JpaRepositories are not working out for you. They are there for basic CRUD operations, definitely not to add business logic.
– lgaleazzi
Nov 8 at 11:33
add a comment |
up vote
0
down vote
There are several ways to do this depending on what you're trying to do:
- Use method naming, and let Spring derive the JPQL query from the naming (https://www.petrikainulainen.net/programming/spring-framework/spring-data-jpa-tutorial-creating-database-queries-from-method-names/)
- Use the Query annotation and add the desired JPQL query in the annotation (https://www.petrikainulainen.net/programming/spring-framework/spring-data-jpa-tutorial-creating-database-queries-with-the-query-annotation/)
- Use a named query (https://www.petrikainulainen.net/programming/spring-framework/spring-data-jpa-tutorial-creating-database-queries-with-named-queries/)
I prefer to use method naming if possible, the method name gets long, but you know exactly what it does by looking at it.
The thing is that I really need to override the delete method and do some stuff in the code before the User gets deleted so just SQL stuff may not do the whole trick.
– epsilonmajorquezero
Nov 8 at 11:12
Then you should do that in the service layer, not in the repository.
– lgaleazzi
Nov 8 at 11:14
Then I'm afraid someone without much idea of what's happening will come and just callUserRepo.dele(myUser)
and mess up with the data in the DB.
– epsilonmajorquezero
Nov 8 at 11:22
Then I guess JpaRepositories are not working out for you. They are there for basic CRUD operations, definitely not to add business logic.
– lgaleazzi
Nov 8 at 11:33
add a comment |
up vote
0
down vote
up vote
0
down vote
There are several ways to do this depending on what you're trying to do:
- Use method naming, and let Spring derive the JPQL query from the naming (https://www.petrikainulainen.net/programming/spring-framework/spring-data-jpa-tutorial-creating-database-queries-from-method-names/)
- Use the Query annotation and add the desired JPQL query in the annotation (https://www.petrikainulainen.net/programming/spring-framework/spring-data-jpa-tutorial-creating-database-queries-with-the-query-annotation/)
- Use a named query (https://www.petrikainulainen.net/programming/spring-framework/spring-data-jpa-tutorial-creating-database-queries-with-named-queries/)
I prefer to use method naming if possible, the method name gets long, but you know exactly what it does by looking at it.
There are several ways to do this depending on what you're trying to do:
- Use method naming, and let Spring derive the JPQL query from the naming (https://www.petrikainulainen.net/programming/spring-framework/spring-data-jpa-tutorial-creating-database-queries-from-method-names/)
- Use the Query annotation and add the desired JPQL query in the annotation (https://www.petrikainulainen.net/programming/spring-framework/spring-data-jpa-tutorial-creating-database-queries-with-the-query-annotation/)
- Use a named query (https://www.petrikainulainen.net/programming/spring-framework/spring-data-jpa-tutorial-creating-database-queries-with-named-queries/)
I prefer to use method naming if possible, the method name gets long, but you know exactly what it does by looking at it.
answered Nov 8 at 11:02
lgaleazzi
537
537
The thing is that I really need to override the delete method and do some stuff in the code before the User gets deleted so just SQL stuff may not do the whole trick.
– epsilonmajorquezero
Nov 8 at 11:12
Then you should do that in the service layer, not in the repository.
– lgaleazzi
Nov 8 at 11:14
Then I'm afraid someone without much idea of what's happening will come and just callUserRepo.dele(myUser)
and mess up with the data in the DB.
– epsilonmajorquezero
Nov 8 at 11:22
Then I guess JpaRepositories are not working out for you. They are there for basic CRUD operations, definitely not to add business logic.
– lgaleazzi
Nov 8 at 11:33
add a comment |
The thing is that I really need to override the delete method and do some stuff in the code before the User gets deleted so just SQL stuff may not do the whole trick.
– epsilonmajorquezero
Nov 8 at 11:12
Then you should do that in the service layer, not in the repository.
– lgaleazzi
Nov 8 at 11:14
Then I'm afraid someone without much idea of what's happening will come and just callUserRepo.dele(myUser)
and mess up with the data in the DB.
– epsilonmajorquezero
Nov 8 at 11:22
Then I guess JpaRepositories are not working out for you. They are there for basic CRUD operations, definitely not to add business logic.
– lgaleazzi
Nov 8 at 11:33
The thing is that I really need to override the delete method and do some stuff in the code before the User gets deleted so just SQL stuff may not do the whole trick.
– epsilonmajorquezero
Nov 8 at 11:12
The thing is that I really need to override the delete method and do some stuff in the code before the User gets deleted so just SQL stuff may not do the whole trick.
– epsilonmajorquezero
Nov 8 at 11:12
Then you should do that in the service layer, not in the repository.
– lgaleazzi
Nov 8 at 11:14
Then you should do that in the service layer, not in the repository.
– lgaleazzi
Nov 8 at 11:14
Then I'm afraid someone without much idea of what's happening will come and just call
UserRepo.dele(myUser)
and mess up with the data in the DB.– epsilonmajorquezero
Nov 8 at 11:22
Then I'm afraid someone without much idea of what's happening will come and just call
UserRepo.dele(myUser)
and mess up with the data in the DB.– epsilonmajorquezero
Nov 8 at 11:22
Then I guess JpaRepositories are not working out for you. They are there for basic CRUD operations, definitely not to add business logic.
– lgaleazzi
Nov 8 at 11:33
Then I guess JpaRepositories are not working out for you. They are there for basic CRUD operations, definitely not to add business logic.
– lgaleazzi
Nov 8 at 11:33
add a comment |
up vote
0
down vote
In your case code will be like as below:
public interface UserRepo extends JpaRepository<User, Long>
{
findUserById(long id);
findUserByEmail(String email);
// etc...
}
public interface UserRepositoryCustom {
void deleteByEmail(String email);
}
public interface UserRepositoryImpl implements UserRepositoryCustom {
public void deleteByEmail(String email) {
//provide your custom implimentation
}
}
Yeah, I know I can do that but is thedelete(T entity)
that I want to override to prevent an unaware developer from calling it instead of thedeleteByEmail
with custom behaviour and messing stuff becausedelete
is not doing what it should but still deleting the Entity in the data base.
– epsilonmajorquezero
Nov 8 at 11:03
Ok Then you can create you custom Repository interface and then provide custom implementation.
– Raheela Aslam
Nov 8 at 11:07
That's what I also commented on the post. If I provide a custom implementation then I have to implement all thefindByX
methodfs too which is quite a bit of extra work and me messing with SQL more than I'd like too in that case :)
– epsilonmajorquezero
Nov 8 at 11:10
1
No you have to create UserRepository and UserRepositoryCustom in custom you can add methods that you want to provide custom implementation.
– Raheela Aslam
Nov 8 at 11:13
Ok, now I understand what you emant and yeah, I know this approach is possible but hoped for something nicer to exist. I'll end up doing that if there's nothing better.
– epsilonmajorquezero
Nov 8 at 11:27
add a comment |
up vote
0
down vote
In your case code will be like as below:
public interface UserRepo extends JpaRepository<User, Long>
{
findUserById(long id);
findUserByEmail(String email);
// etc...
}
public interface UserRepositoryCustom {
void deleteByEmail(String email);
}
public interface UserRepositoryImpl implements UserRepositoryCustom {
public void deleteByEmail(String email) {
//provide your custom implimentation
}
}
Yeah, I know I can do that but is thedelete(T entity)
that I want to override to prevent an unaware developer from calling it instead of thedeleteByEmail
with custom behaviour and messing stuff becausedelete
is not doing what it should but still deleting the Entity in the data base.
– epsilonmajorquezero
Nov 8 at 11:03
Ok Then you can create you custom Repository interface and then provide custom implementation.
– Raheela Aslam
Nov 8 at 11:07
That's what I also commented on the post. If I provide a custom implementation then I have to implement all thefindByX
methodfs too which is quite a bit of extra work and me messing with SQL more than I'd like too in that case :)
– epsilonmajorquezero
Nov 8 at 11:10
1
No you have to create UserRepository and UserRepositoryCustom in custom you can add methods that you want to provide custom implementation.
– Raheela Aslam
Nov 8 at 11:13
Ok, now I understand what you emant and yeah, I know this approach is possible but hoped for something nicer to exist. I'll end up doing that if there's nothing better.
– epsilonmajorquezero
Nov 8 at 11:27
add a comment |
up vote
0
down vote
up vote
0
down vote
In your case code will be like as below:
public interface UserRepo extends JpaRepository<User, Long>
{
findUserById(long id);
findUserByEmail(String email);
// etc...
}
public interface UserRepositoryCustom {
void deleteByEmail(String email);
}
public interface UserRepositoryImpl implements UserRepositoryCustom {
public void deleteByEmail(String email) {
//provide your custom implimentation
}
}
In your case code will be like as below:
public interface UserRepo extends JpaRepository<User, Long>
{
findUserById(long id);
findUserByEmail(String email);
// etc...
}
public interface UserRepositoryCustom {
void deleteByEmail(String email);
}
public interface UserRepositoryImpl implements UserRepositoryCustom {
public void deleteByEmail(String email) {
//provide your custom implimentation
}
}
edited Nov 8 at 11:14
answered Nov 8 at 10:57
Raheela Aslam
3327
3327
Yeah, I know I can do that but is thedelete(T entity)
that I want to override to prevent an unaware developer from calling it instead of thedeleteByEmail
with custom behaviour and messing stuff becausedelete
is not doing what it should but still deleting the Entity in the data base.
– epsilonmajorquezero
Nov 8 at 11:03
Ok Then you can create you custom Repository interface and then provide custom implementation.
– Raheela Aslam
Nov 8 at 11:07
That's what I also commented on the post. If I provide a custom implementation then I have to implement all thefindByX
methodfs too which is quite a bit of extra work and me messing with SQL more than I'd like too in that case :)
– epsilonmajorquezero
Nov 8 at 11:10
1
No you have to create UserRepository and UserRepositoryCustom in custom you can add methods that you want to provide custom implementation.
– Raheela Aslam
Nov 8 at 11:13
Ok, now I understand what you emant and yeah, I know this approach is possible but hoped for something nicer to exist. I'll end up doing that if there's nothing better.
– epsilonmajorquezero
Nov 8 at 11:27
add a comment |
Yeah, I know I can do that but is thedelete(T entity)
that I want to override to prevent an unaware developer from calling it instead of thedeleteByEmail
with custom behaviour and messing stuff becausedelete
is not doing what it should but still deleting the Entity in the data base.
– epsilonmajorquezero
Nov 8 at 11:03
Ok Then you can create you custom Repository interface and then provide custom implementation.
– Raheela Aslam
Nov 8 at 11:07
That's what I also commented on the post. If I provide a custom implementation then I have to implement all thefindByX
methodfs too which is quite a bit of extra work and me messing with SQL more than I'd like too in that case :)
– epsilonmajorquezero
Nov 8 at 11:10
1
No you have to create UserRepository and UserRepositoryCustom in custom you can add methods that you want to provide custom implementation.
– Raheela Aslam
Nov 8 at 11:13
Ok, now I understand what you emant and yeah, I know this approach is possible but hoped for something nicer to exist. I'll end up doing that if there's nothing better.
– epsilonmajorquezero
Nov 8 at 11:27
Yeah, I know I can do that but is the
delete(T entity)
that I want to override to prevent an unaware developer from calling it instead of the deleteByEmail
with custom behaviour and messing stuff because delete
is not doing what it should but still deleting the Entity in the data base.– epsilonmajorquezero
Nov 8 at 11:03
Yeah, I know I can do that but is the
delete(T entity)
that I want to override to prevent an unaware developer from calling it instead of the deleteByEmail
with custom behaviour and messing stuff because delete
is not doing what it should but still deleting the Entity in the data base.– epsilonmajorquezero
Nov 8 at 11:03
Ok Then you can create you custom Repository interface and then provide custom implementation.
– Raheela Aslam
Nov 8 at 11:07
Ok Then you can create you custom Repository interface and then provide custom implementation.
– Raheela Aslam
Nov 8 at 11:07
That's what I also commented on the post. If I provide a custom implementation then I have to implement all the
findByX
methodfs too which is quite a bit of extra work and me messing with SQL more than I'd like too in that case :)– epsilonmajorquezero
Nov 8 at 11:10
That's what I also commented on the post. If I provide a custom implementation then I have to implement all the
findByX
methodfs too which is quite a bit of extra work and me messing with SQL more than I'd like too in that case :)– epsilonmajorquezero
Nov 8 at 11:10
1
1
No you have to create UserRepository and UserRepositoryCustom in custom you can add methods that you want to provide custom implementation.
– Raheela Aslam
Nov 8 at 11:13
No you have to create UserRepository and UserRepositoryCustom in custom you can add methods that you want to provide custom implementation.
– Raheela Aslam
Nov 8 at 11:13
Ok, now I understand what you emant and yeah, I know this approach is possible but hoped for something nicer to exist. I'll end up doing that if there's nothing better.
– epsilonmajorquezero
Nov 8 at 11:27
Ok, now I understand what you emant and yeah, I know this approach is possible but hoped for something nicer to exist. I'll end up doing that if there's nothing better.
– epsilonmajorquezero
Nov 8 at 11:27
add a comment |
up vote
0
down vote
If you want to keep Spring's behavior for deletion, but want to have some logic to be executed either before or after, you may utilize java8's interface default methods, and try the following :
public interface UserRepo extends JpaRepository<User, Long> {
default void customDelete(User user) {
// before logic
// ..
delete(user); // actual call to deletion
// after logic
// ..
}
}
Nope, that wouldn't prefent an unaware coder from calling regular delete by mistake. And you can't write code in an interface, can you?
– epsilonmajorquezero
Nov 8 at 12:00
From java 8 onwards, yes you can. Look at docs for more info docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html
– Elg
Nov 8 at 12:05
add a comment |
up vote
0
down vote
If you want to keep Spring's behavior for deletion, but want to have some logic to be executed either before or after, you may utilize java8's interface default methods, and try the following :
public interface UserRepo extends JpaRepository<User, Long> {
default void customDelete(User user) {
// before logic
// ..
delete(user); // actual call to deletion
// after logic
// ..
}
}
Nope, that wouldn't prefent an unaware coder from calling regular delete by mistake. And you can't write code in an interface, can you?
– epsilonmajorquezero
Nov 8 at 12:00
From java 8 onwards, yes you can. Look at docs for more info docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html
– Elg
Nov 8 at 12:05
add a comment |
up vote
0
down vote
up vote
0
down vote
If you want to keep Spring's behavior for deletion, but want to have some logic to be executed either before or after, you may utilize java8's interface default methods, and try the following :
public interface UserRepo extends JpaRepository<User, Long> {
default void customDelete(User user) {
// before logic
// ..
delete(user); // actual call to deletion
// after logic
// ..
}
}
If you want to keep Spring's behavior for deletion, but want to have some logic to be executed either before or after, you may utilize java8's interface default methods, and try the following :
public interface UserRepo extends JpaRepository<User, Long> {
default void customDelete(User user) {
// before logic
// ..
delete(user); // actual call to deletion
// after logic
// ..
}
}
answered Nov 8 at 11:43
Elg
1313
1313
Nope, that wouldn't prefent an unaware coder from calling regular delete by mistake. And you can't write code in an interface, can you?
– epsilonmajorquezero
Nov 8 at 12:00
From java 8 onwards, yes you can. Look at docs for more info docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html
– Elg
Nov 8 at 12:05
add a comment |
Nope, that wouldn't prefent an unaware coder from calling regular delete by mistake. And you can't write code in an interface, can you?
– epsilonmajorquezero
Nov 8 at 12:00
From java 8 onwards, yes you can. Look at docs for more info docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html
– Elg
Nov 8 at 12:05
Nope, that wouldn't prefent an unaware coder from calling regular delete by mistake. And you can't write code in an interface, can you?
– epsilonmajorquezero
Nov 8 at 12:00
Nope, that wouldn't prefent an unaware coder from calling regular delete by mistake. And you can't write code in an interface, can you?
– epsilonmajorquezero
Nov 8 at 12:00
From java 8 onwards, yes you can. Look at docs for more info docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html
– Elg
Nov 8 at 12:05
From java 8 onwards, yes you can. Look at docs for more info docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html
– Elg
Nov 8 at 12:05
add a comment |
up vote
0
down vote
Hi you can write your own Interface write implementation with EntityManager and
extend in you interface here is the sample :
- https://dzone.com/articles/accessing-the-entitymanager-from-spring-data-jpa
Actually one more way is writing by soemthing like :
User findByUsername(String username) // it will find the user by specific username
spring data will create you an implementation of this method
The same way you can create your own delete method
Here is useful links:
https://docs.spring.io/spring-data/jpa/docs/current/reference/html/#repositories.custom-implementations
In this link you can go to part 2.3 QueryMethods:
- https://docs.spring.io/spring-data/jpa/docs/1.6.0.RELEASE/reference/html/jpa.repositories.html
You can also define @NameQuery in your entity class:
@Entity
@Table(name = "employee", schema="spring_data_jpa_example")
@NamedQuery(name = "Employee.yourMethodQueryName",
query = "yourQuery"
)
public class Employee {}
@Repository
public interface EmployeeRepository extends JpaRepository<Employee,Long> {
List<Employee> yourMethodQueryName(Your list of params);
}
Here is link with sample:
- https://www.logicbig.com/tutorials/spring-framework/spring-data/jpa-named-queries.html
I think this is helpful for you
I expected something a bit nicer (like calling some code in the Entity itself) than the custom repo for delete but I'll endup doing that if necessary :)
– epsilonmajorquezero
Nov 8 at 11:29
Updated answer you can look)
– Mykhailo Moskura
Nov 8 at 11:55
Thanks, but what I actually want is to call some code on the soonToBeDeleted entity and then delete it, not just SQL :)
– epsilonmajorquezero
Nov 8 at 12:02
add a comment |
up vote
0
down vote
Hi you can write your own Interface write implementation with EntityManager and
extend in you interface here is the sample :
- https://dzone.com/articles/accessing-the-entitymanager-from-spring-data-jpa
Actually one more way is writing by soemthing like :
User findByUsername(String username) // it will find the user by specific username
spring data will create you an implementation of this method
The same way you can create your own delete method
Here is useful links:
https://docs.spring.io/spring-data/jpa/docs/current/reference/html/#repositories.custom-implementations
In this link you can go to part 2.3 QueryMethods:
- https://docs.spring.io/spring-data/jpa/docs/1.6.0.RELEASE/reference/html/jpa.repositories.html
You can also define @NameQuery in your entity class:
@Entity
@Table(name = "employee", schema="spring_data_jpa_example")
@NamedQuery(name = "Employee.yourMethodQueryName",
query = "yourQuery"
)
public class Employee {}
@Repository
public interface EmployeeRepository extends JpaRepository<Employee,Long> {
List<Employee> yourMethodQueryName(Your list of params);
}
Here is link with sample:
- https://www.logicbig.com/tutorials/spring-framework/spring-data/jpa-named-queries.html
I think this is helpful for you
I expected something a bit nicer (like calling some code in the Entity itself) than the custom repo for delete but I'll endup doing that if necessary :)
– epsilonmajorquezero
Nov 8 at 11:29
Updated answer you can look)
– Mykhailo Moskura
Nov 8 at 11:55
Thanks, but what I actually want is to call some code on the soonToBeDeleted entity and then delete it, not just SQL :)
– epsilonmajorquezero
Nov 8 at 12:02
add a comment |
up vote
0
down vote
up vote
0
down vote
Hi you can write your own Interface write implementation with EntityManager and
extend in you interface here is the sample :
- https://dzone.com/articles/accessing-the-entitymanager-from-spring-data-jpa
Actually one more way is writing by soemthing like :
User findByUsername(String username) // it will find the user by specific username
spring data will create you an implementation of this method
The same way you can create your own delete method
Here is useful links:
https://docs.spring.io/spring-data/jpa/docs/current/reference/html/#repositories.custom-implementations
In this link you can go to part 2.3 QueryMethods:
- https://docs.spring.io/spring-data/jpa/docs/1.6.0.RELEASE/reference/html/jpa.repositories.html
You can also define @NameQuery in your entity class:
@Entity
@Table(name = "employee", schema="spring_data_jpa_example")
@NamedQuery(name = "Employee.yourMethodQueryName",
query = "yourQuery"
)
public class Employee {}
@Repository
public interface EmployeeRepository extends JpaRepository<Employee,Long> {
List<Employee> yourMethodQueryName(Your list of params);
}
Here is link with sample:
- https://www.logicbig.com/tutorials/spring-framework/spring-data/jpa-named-queries.html
I think this is helpful for you
Hi you can write your own Interface write implementation with EntityManager and
extend in you interface here is the sample :
- https://dzone.com/articles/accessing-the-entitymanager-from-spring-data-jpa
Actually one more way is writing by soemthing like :
User findByUsername(String username) // it will find the user by specific username
spring data will create you an implementation of this method
The same way you can create your own delete method
Here is useful links:
https://docs.spring.io/spring-data/jpa/docs/current/reference/html/#repositories.custom-implementations
In this link you can go to part 2.3 QueryMethods:
- https://docs.spring.io/spring-data/jpa/docs/1.6.0.RELEASE/reference/html/jpa.repositories.html
You can also define @NameQuery in your entity class:
@Entity
@Table(name = "employee", schema="spring_data_jpa_example")
@NamedQuery(name = "Employee.yourMethodQueryName",
query = "yourQuery"
)
public class Employee {}
@Repository
public interface EmployeeRepository extends JpaRepository<Employee,Long> {
List<Employee> yourMethodQueryName(Your list of params);
}
Here is link with sample:
- https://www.logicbig.com/tutorials/spring-framework/spring-data/jpa-named-queries.html
I think this is helpful for you
edited Nov 8 at 11:54
answered Nov 8 at 11:02
Mykhailo Moskura
50812
50812
I expected something a bit nicer (like calling some code in the Entity itself) than the custom repo for delete but I'll endup doing that if necessary :)
– epsilonmajorquezero
Nov 8 at 11:29
Updated answer you can look)
– Mykhailo Moskura
Nov 8 at 11:55
Thanks, but what I actually want is to call some code on the soonToBeDeleted entity and then delete it, not just SQL :)
– epsilonmajorquezero
Nov 8 at 12:02
add a comment |
I expected something a bit nicer (like calling some code in the Entity itself) than the custom repo for delete but I'll endup doing that if necessary :)
– epsilonmajorquezero
Nov 8 at 11:29
Updated answer you can look)
– Mykhailo Moskura
Nov 8 at 11:55
Thanks, but what I actually want is to call some code on the soonToBeDeleted entity and then delete it, not just SQL :)
– epsilonmajorquezero
Nov 8 at 12:02
I expected something a bit nicer (like calling some code in the Entity itself) than the custom repo for delete but I'll endup doing that if necessary :)
– epsilonmajorquezero
Nov 8 at 11:29
I expected something a bit nicer (like calling some code in the Entity itself) than the custom repo for delete but I'll endup doing that if necessary :)
– epsilonmajorquezero
Nov 8 at 11:29
Updated answer you can look)
– Mykhailo Moskura
Nov 8 at 11:55
Updated answer you can look)
– Mykhailo Moskura
Nov 8 at 11:55
Thanks, but what I actually want is to call some code on the soonToBeDeleted entity and then delete it, not just SQL :)
– epsilonmajorquezero
Nov 8 at 12:02
Thanks, but what I actually want is to call some code on the soonToBeDeleted entity and then delete it, not just SQL :)
– epsilonmajorquezero
Nov 8 at 12:02
add a comment |
up vote
0
down vote
public interface UserRepo extends JpaRepository<User, Long> {
@Modifying
@Query("delete from User u where u.email = ?1")
void deleteByEmail(String email);
}
That wouldn't override thedelete
method which is what (I think) I need to do :)
– epsilonmajorquezero
Nov 8 at 11:05
While this code snippet may solve the problem, it doesn't explain why or how it answers the question. Please include an explanation for your code, as that really helps to improve the quality of your post. Remember that you are answering the question for readers in the future, and those people might not know the reasons for your code suggestion.
– Luca Kiebel
Nov 8 at 12:27
This does not provide an answer to the question. Once you have sufficient reputation you will be able to comment on any post; instead, provide answers that don't require clarification from the asker. - From Review
– Harsh
Nov 8 at 18:00
stackoverflow.com/questions/43665090/…
– Faisal Mk
Nov 9 at 5:05
add a comment |
up vote
0
down vote
public interface UserRepo extends JpaRepository<User, Long> {
@Modifying
@Query("delete from User u where u.email = ?1")
void deleteByEmail(String email);
}
That wouldn't override thedelete
method which is what (I think) I need to do :)
– epsilonmajorquezero
Nov 8 at 11:05
While this code snippet may solve the problem, it doesn't explain why or how it answers the question. Please include an explanation for your code, as that really helps to improve the quality of your post. Remember that you are answering the question for readers in the future, and those people might not know the reasons for your code suggestion.
– Luca Kiebel
Nov 8 at 12:27
This does not provide an answer to the question. Once you have sufficient reputation you will be able to comment on any post; instead, provide answers that don't require clarification from the asker. - From Review
– Harsh
Nov 8 at 18:00
stackoverflow.com/questions/43665090/…
– Faisal Mk
Nov 9 at 5:05
add a comment |
up vote
0
down vote
up vote
0
down vote
public interface UserRepo extends JpaRepository<User, Long> {
@Modifying
@Query("delete from User u where u.email = ?1")
void deleteByEmail(String email);
}
public interface UserRepo extends JpaRepository<User, Long> {
@Modifying
@Query("delete from User u where u.email = ?1")
void deleteByEmail(String email);
}
edited Nov 9 at 5:04
answered Nov 8 at 11:03
Faisal Mk
765
765
That wouldn't override thedelete
method which is what (I think) I need to do :)
– epsilonmajorquezero
Nov 8 at 11:05
While this code snippet may solve the problem, it doesn't explain why or how it answers the question. Please include an explanation for your code, as that really helps to improve the quality of your post. Remember that you are answering the question for readers in the future, and those people might not know the reasons for your code suggestion.
– Luca Kiebel
Nov 8 at 12:27
This does not provide an answer to the question. Once you have sufficient reputation you will be able to comment on any post; instead, provide answers that don't require clarification from the asker. - From Review
– Harsh
Nov 8 at 18:00
stackoverflow.com/questions/43665090/…
– Faisal Mk
Nov 9 at 5:05
add a comment |
That wouldn't override thedelete
method which is what (I think) I need to do :)
– epsilonmajorquezero
Nov 8 at 11:05
While this code snippet may solve the problem, it doesn't explain why or how it answers the question. Please include an explanation for your code, as that really helps to improve the quality of your post. Remember that you are answering the question for readers in the future, and those people might not know the reasons for your code suggestion.
– Luca Kiebel
Nov 8 at 12:27
This does not provide an answer to the question. Once you have sufficient reputation you will be able to comment on any post; instead, provide answers that don't require clarification from the asker. - From Review
– Harsh
Nov 8 at 18:00
stackoverflow.com/questions/43665090/…
– Faisal Mk
Nov 9 at 5:05
That wouldn't override the
delete
method which is what (I think) I need to do :)– epsilonmajorquezero
Nov 8 at 11:05
That wouldn't override the
delete
method which is what (I think) I need to do :)– epsilonmajorquezero
Nov 8 at 11:05
While this code snippet may solve the problem, it doesn't explain why or how it answers the question. Please include an explanation for your code, as that really helps to improve the quality of your post. Remember that you are answering the question for readers in the future, and those people might not know the reasons for your code suggestion.
– Luca Kiebel
Nov 8 at 12:27
While this code snippet may solve the problem, it doesn't explain why or how it answers the question. Please include an explanation for your code, as that really helps to improve the quality of your post. Remember that you are answering the question for readers in the future, and those people might not know the reasons for your code suggestion.
– Luca Kiebel
Nov 8 at 12:27
This does not provide an answer to the question. Once you have sufficient reputation you will be able to comment on any post; instead, provide answers that don't require clarification from the asker. - From Review
– Harsh
Nov 8 at 18:00
This does not provide an answer to the question. Once you have sufficient reputation you will be able to comment on any post; instead, provide answers that don't require clarification from the asker. - From Review
– Harsh
Nov 8 at 18:00
stackoverflow.com/questions/43665090/…
– Faisal Mk
Nov 9 at 5:05
stackoverflow.com/questions/43665090/…
– Faisal Mk
Nov 9 at 5:05
add a comment |
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53206163%2fcustom-delete-method-in-jparepository%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Please have a look into below issue somehow it related: stackoverflow.com/questions/39923434/…
– Raheela Aslam
Nov 8 at 10:53
Nope, that's not what I wanted to achieve.
– epsilonmajorquezero
Nov 8 at 11:12