I have my spring boot app. in which I have written below code at daoImpl layer.
#Autowired
EntityManager
CriteriaBuilder qb = em.getCriteriaBuilder();
CriteriaQuery<Person> c = qb.createQuery(Person.class);
Root<Person> p = c.from(Person.class);
where "Person" in an #Entity class placed in separate "commons" package.
It's throwing exception "Not an entity.." on second line although it passes the first line.
Can someone help me out with the probable causes. This looks something weird to me since the same entity is been accepted on previous line but not on next line.
Irrespective of you problem generally speaking You can not have a table with name 'Order' because it is a keyword in sql.
Change it to something else and check it will work.
See this if you still want to use any keyword.
I got the solution for this, we should use #EntityScan instead of #ComponentScan to find the package of entity if it's in separate project.
Related
I have a spring boot application (based off spring-boot-starter-data-jpa. I have an absolute minimum of configuration going on, and only a single table and entity.
I'm using CrudRepository<Long, MyEntity> with a couple of findBy methods which all work. And I have a derived deleteBy method - which doesn't work. The signature is simply:
public interface MyEntityRepository<Long, MyEntity> extends CrudRespository<> {
Long deleteBySystemId(String systemId);
// findBy methods left out
}
The entity is simple, too:
#Entity #Table(name="MyEntityTable")
public class MyEntity {
#Id
#GeneratedValue(strategy=GenerationType.IDENTITY)
#Column(name="MyEntityPID")
private Long MyEntityPID;
#Column(name="SystemId")
private String systemId;
#Column(name="PersonIdentifier")
private String personIdentifier;
// Getters and setters here, also hashCode & equals.
}
The reason the deleteBy method isn't working is because it seems to only issue a "select" statement to the database, which selects all the MyEntity rows which has a SystemId with the value I specify. Using my mysql global log I have captured the actual, physical sql and issued it manually on the database, and verified that it returns a large number of rows.
So Spring, or rather Hibernate, is trying to select the rows it has to delete, but it never actually issues a DELETE FROM statement.
According to a note on Baeldung this select statement is normal, in the sense that Hibernate will first select all rows that it intends to delete, then issue delete statements for each of them.
Does anyone know why this derived deleteBy method would not be working? I have #TransactionManagementEnabled on my #Configuration, and the method calling is #Transactional. The mysql log shows that spring sets autocommit=0 so it seems like transactions are properly enabled.
I have worked around this issue by manually annotating the derived delete method this way:
public interface MyEntityRepository<Long, MyEntity> extends CrudRespository<> {
#Modifying
#Query("DELETE FROM MyEntity m where m.systemId=:systemId")
Long deleteBySystemId(#Param("systemId") String systemId);
// findBy methods left out
}
This works. Including transactions. But this just shouldn't have to be, I shouldn't need to add that Query annotation.
Here is a person who has the exact same problem as I do. However the Spring developers were quick to wash their hands and write it off as a Hibernate problem so no solution or explanation to be found there.
Oh, for reference I'm using Spring Boot 2.2.9.
tl;dr
It's all in the reference documentation. That's the way JPA works. (Me rubbing hands washing.)
Details
The two methods do two different things: Long deleteBySystemId(String systemId); loads the entity by the given constraints and ends up issuing EntityManager.delete(…) which the persistence provider is about to delay until transaction commits. I.e. code following that call is not guaranteed that the changes have already been synced to the database. That in turn is due to JPA allowing its implementations to actually do just that. Unfortunately that's nothing Spring Data can fix on top of that. (More rubbing, more washing, plus a bit of soap.)
The reference documentation justifies that behavior with the need for the EntityManager (again a JPA abstraction, not something Spring Data has anything to do with) to trigger lifecycle events like #PreDelete etc. which users expect to fire.
The second method declaring a modifying query manually is declaring a query to be executed in the database, which means that entity lifecycles do not fire as the entities do not get materialized upfront.
However the Spring developers were quick to wash their hands and write it off as a Hibernate problem so no solution or explanation to be found there.
There's detailed explanation why it works the way it works in the comments to the ticket. There are solutions provided even. Workarounds and suggestions to bring this up with the part of the stack that has control over this behavior. (Shuts faucet, reaches for a towel.)
We are currently working on web application with persistence layer implemented using Spring data JPA and its working out really well for us however while scanning our code using checkmarx it complains for "Improper Resource Access Authorization" error for all input parameter in below code snippet.Not sure how to resolve it.Based of my understanding we tried following approach but that didn't help either
Whitelist input parameter using using #valid and #Pattern
annotations
Secure method using #Secured("ROLE_TEST") annotation of spring security.
#Repository
public interface EmployeeAddressRepository extends JpaRepository<EmployeeAddress, Integer> {
#Query("select empAdd from EmployeeAddress empAdd where empAdd.Employee.employeeId=?1 and (endDate) ORDER BY empAdd.lastUpdateTimeStamp DESC")
List<EmployeeAddress> findEmployeeAddressByEmployeeId(String employeeId, LocalDate date) throws PersistenceException;
}
Looking forward for any pointer here to move forward in right direction
In the comments for one of the other answers someone provided the answer. Essentially Checkmarx is unable to determine if you are checking if the user/service has permission to execute this command.
A secure implementation would look like:
if(userCanPerformAction(employeeId)){
repository.findEmployeeAddressByEmployeeId(employeeId, date)
}
It's not smart enough to know if your code prior to the call to the repository has actually performed the checks needed. So, what you have to do is verify that you are doing the correct validation checks before executing findEmployeeAddressByEmployeeId. If you are, then you would follow your organizations process for marking something as a false positive.
Perhaps Checkmarx doesn't support ordinal parameters notation, try rewriting the query like so:
#Query("select empAdd from EmployeeAddress empAdd where empAdd.Employee.employeeId= :empId and (endDate) ORDER BY empAdd.lastUpdateTimeStamp DESC", employeeIdParameter)
where employeeIdParameter is the input parameter.
Hope this helps,
Amit
I started with smaller projects to learn how to use Spring. Actually I have a big problem.
Code Redundacy
Maybe I missunderstood something but I have #Entity Classes to describe how my SQL Tables/Structure must be. On the otherside I have serializable classes. Example:
#Entity class UserEntity
and
class User implements Serializable
On CRUD operations I must transfer Values between this two. But why? This two classes are like the same for me. They have same members and getters/setters. Is there an elegant way to avoid this redundacy?
Maybe I do it completley wrong?
I would assume that your question is "Why do I need to make DTO for Entities? Isn't that redutant?"
Simple answer : Safety reason.
Complex answer :
So there are some risk with JSP and MVC where if you put your managed entities into frontend, there are posibilities where you can inject data into database. Which is bad for site of course : )
For more detail information check https://o2platform.files.wordpress.com/2011/07/ounce_springframework_vulnerabilities.pdf
I am using Spring Data rest with Spring JPA. I have one Spring JPA derived delete query that should deletes the list of items but when I am executing it and noticing the console I found that it is executing select query instead that's very strange situation I have ever come across.
#RepositoryRestResource(collectionResourceRel="revision", path="revision")
interface RevisionRepository extends JpaRepository<Revision, Long> {
List<Revision> deleteByContentId(long contentId)
}
I have even tried using Long instead of List<Revision> doesn't work and also have tried removeByContentId it is also doesn't work either and keeps executing the select query instead delete query.
when I am running this method this is what I got on my console
Hibernate: select revision0_.id as id1_2_, revision0_.body as body2_2_, revision0_.content_id as content_3_2_, revision0_.content_type as content_4_2_, revision0_.date_created as date_cre5_2_, revision0_.file_name as file_nam6_2_, revision0_.folder_id as folder_i7_2_, revision0_.force_ssl as force_ss8_2_, revision0_.is_active as is_activ9_2_, revision0_.lookup as lookup10_2_, revision0_.meta_description as meta_de11_2_, revision0_.meta_keywords as meta_ke12_2_, revision0_.meta_title as meta_ti13_2_, revision0_.nav_item as nav_ite14_2_, revision0_.nav_order as nav_ord15_2_, revision0_.regions_objects as regions16_2_, revision0_.summary as summary17_2_, revision0_.title as title18_2_, revision0_.updated_by as updated19_2_, revision0_.user_id as user_id20_2_ from revisions revision0_ where revision0_.content_id=?
does anyone having any idea why it is behaving strangely?
You need to add #Modifying annotation to your delete method. You will also need to make sure it is executed within a transaction, so you might need to add #Transactional annotation too, if you invoke this method not in a transaction.
Please see an example:
#Modifying
#Transactional
int deleteByFieldName( Long fieldValue );
In latest Spring >=5 and Spring Boot >=2.
#Transactional
int deleteByFieldname( Long fieldValue );
Works fine.
Note 1:
#Modifiyng annotation has absolutely no effect in this. It only work for #Query annotation. Without #Query, it is simply ignored.
Note 2:
In naming convention, that depends on the configured NamingStrategy, the CamelCase might be interpreted and nested entity relation or "_" in field name. So "Fieldname" and "FieldName" mean very different things.
Note 3:
Derived delete queries like this have a really nasty n+1 side effect. They ALWAYS first issue select for the rows then isses delete each row/entity one by one with separate delete stement. No way around this, except using #Query() with manual delete statement. And using #Query then requires the #Modifying for delete query.
I have an JPA Entity which I Would like to use for 2 Tables.
#Entity
#Table(name="table_name_should_be_injected")
class MyEntity{
// Implementation goes here
}
So I would like to inject the table name with Spring.
Is this possible?
Please don't pursue this line of design. It will add a completely unnecessary level of complexity to your solution, it goes against the JPA specification and intention and it will leave anyone else looking at your solution scratching their heads.
The proper way to accomplish this in JPA is with an abstract base-class and #Inheritance(strategy=TABLE_PER_CLASS) (see #Inheritance).