I'm trying to setup a project using Slim and Doctrine. My problem is with the annotations.
If I try to run diff from migrations, it requires the annotations from my entities to be like this:
But, if I try to persist my objects in PHP ORM, it requires the annotation to be like this:
I'm not beeing able to find a way to configure doctrine to work with just one type of annotation
I fixed this by when creating the Annotation Configuration for my EntityManager, set it to use the simple annotation reader, which is the last parameter here:
Related
I have a project using Kotlin in Spring Boot. The tables have the standard audit fields 'createdBy', 'createdDt'. Is there a way to handle setting these fields in some way that doesn't involve passing these fields around? Ideally I'd like to intercept every transaction before commit and just set the fields on the entities.
Using JPA and Hibernate, an AuditAware bean could be used to pass the current Principal along with using annotations. Is there a similar integration available or easily implemented? I've looked at the EntityHooks class and don't see an easy way to change data.
I'd like to disable Hibernate validation for a single entity in my application, which I validate manually. The rest of entites should continue to use the standard Hibernate validation on persist.
The standard solution is to disable all validation via javax.persistence.validation.mode: none but this doesn't apply here as I just want to bypass it for a single entity.
So far the solutions appear to be:
Add Hibernate groups to every single annotation on the entity - this is error prone and cumbersome as the entity has 50+ annotations on it.
Replace or override BeanValidationEventListener to skip validation for my entity - there doesn't appear to be a clean way to override this listener with Spring Boot 2.0.
Are there other, simpler ways to do this with Hibernate and Spring?
I have a Spring Boot application and want to use Liquibase to generate the changelogs for my JPA entities. However, I encounter different issues, depending on my approach.
My first approach is to use the diff goal of the maven plugin. The url is my H2 development database with the H2 driver and the reference URL is something like "hibernate:spring:myBasePackage.myEntityPackage?dialect=org.hibernate.dialect.H2Dialect" with the driver "liquibase.ext.hibernate.database.connection.HibernateDriver". In that case Liquibase seems to recognize my entities, but prints the differences to the console. Also the differences do not have the form of a changelog file.
My second approach would be to use the generateChangeLog goal of the maven plugin. In this case my url is "hibernate:spring:myBasePackage.myEntityPackage?dialect=org.hibernate.dialect.H2Dialect" with the driver "liquibase.ext.hibernate.database.connection.HibernateDriver. In this case I am getting an error "Unable to resolve persistence unit root URL: class path resource [] cannot be resolved to URL because it does not exist". This error can be found in both the Spring an the Liquibase issue trackers, but it seems like it is always said that this error is already fixed.
My third approach is basically like the second, but in this case I am using a "hibernate:classic" url with an implementation of "CustomClassicConfigurationFactory", which registers my annotated classes explicitly. This does work. However, in this case I have to do this in my application-jar. I have to add my application-jar as a dependency for the maven-plugin. Thus I have to build my application-jar (and install it to the local Maven repository), before I can generate the changelogs. This seems to be cumbersome.
My questions are:
Is there an easier way to generate the changelogs for JPA entities in a Spring boot based application?
Why are the first two approaches not working?
Is there a way to simplify the third approach?
I am using:
Spring Boot 1.5.4.RELEASE
Liquibase-Hibernate4 3.6
Liquibase 3.5.3
Many thanks in advance.
In the first approach using liquibase:diff , the change set for the entities (create table change set) will not be generated since liquibase do not assume new jpa entity as change.
In the second approach generateChangeLog, it generates the change log from the given data base.It won't look into your jpa entities.
In order to generate the ddl scripts for your jpa entities , just submit the following to your jpa properties
<property key="javax.persistence.schema-generation.scripts.action">drop-and-create</property>
<property key="javax.persistence.schema-generation.scripts.create-target">./ddl/create.sql</property>
<property key="javax.persistence.schema-generation.scripts.drop-target">./ddl/drop.sql</property>
The above will generate the scripts the ddl folder under the root folder.
You can check the other properties here https://thoughts-on-java.org/standardized-schema-generation-data-loading-jpa-2-1/
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
Remove locations attributes from #ConfigurationProperties
What are the alternatives?
I've been using it like this before.
#ConfigurationProperties(locations = "a.yml")
Same problem here: we have hundreds of configuration keys on several yaml files, each of them conveniently mapped to a pojo that we inject into our business logic beans.
The best thing I could do to upgrade to Spring Boot 1.5 and at the same time keep our production application running without much refactoring is described here: http://fabiomaffioletti.me/blog/2016/12/20/spring-configuration-properties-handle-deprecated-locations/
Or, if that does not work for you, you can try this way which is simpler even if requires more refactoring (remove the #ConfigurationProperties annotation): http://fabiomaffioletti.me/blog/2017/02/09/spring-configuration-properties-locations-deprecation-another-approach/