Before migrating to Spring boot 3, we were using the PostgreSQL10Dialect in our apps.
When migrating to Spring boot 3, I realized that Hibernate 6 no longer includes PostgreSQL10Dialect. I cannot find any mention of this in the Hibernate 6 migration guide.
What are we supposed to switch to? PostgreSQL95Dialect ?
I realized that Hibernate 6 no longer includes PostgreSQL10Dialect.
So this is actually a mistake, it was supposed to have been left there as a deprecated stub to smooth migration, but it accidentally got deleted. (I will put it back for Hibernate 6.2.)
But anyway, you don't need it. In Hibernate 6:
you don't usually need to explicitly specify a dialect, the right Dialect is almost always chosen automatically, and
we have moved away from "versioned" dialects, so the right dialect to use is just PostgreSQLDialect.
Related
I have a Spring Data GemFire Region that's configured using annotations below:
#TimeToLiveExpiration(timeout = "100", action = "INVALIDATE")
#PartitionRegion(name = "blockedIPCache")
class BlockedIpEntityType { ... }
My application is a Spring Boot application and I used the following annotations to configure SDG:
#PeerCacheApplication
#EnableGemfireCaching
#EnableCachingDefinedRegions(clientRegionShortcut = ClientRegionShortcut.LOCAL, serverRegionShortcut = RegionShortcut.LOCAL)
#EnableStatistics
#EnableExpiration
#EnableEntityDefinedRegions(basePackageClasses = {...})
#EnableGemfireRepositories(basePackages = {...})
class GemFireConfiguration { ... }
All I want is to insert an object using a Spring Data GemFire Repository and after awhile the entry will be invalidated.
But, I face this Exception when I start my application...
Caused by: java.lang.IllegalStateException: Cannot set idle timeout when statistics are disabled.
at org.apache.geode.internal.cache.AbstractRegion.setCustomEntryIdleTimeout(AbstractRegion.java:1157) ~[geode-core-9.1.1.jar:?]
at org.springframework.data.gemfire.config.annotation.ExpirationConfiguration$ExpirationPolicyMetaData.configure(ExpirationConfiguration.java:511) ~[spring-data-gemfire-2.0.6.RELEASE.jar:2.0.6.RELEASE]
at org.springframework.data.gemfire.config.annotation.ExpirationConfiguration$1.postProcessAfterInitialization(ExpirationConfiguration.java:160) ~[spring-data-gemfire-2.0.6.RELEASE.jar:2.0.6.RELEASE]
...
This happens exactly when Spring tries to autowire my Repository related to the Region configured above.
So what I'm doing wrong? And, is there a way to enable Region statistics using Java configuration or Annotations?
Note: Using Spring Data GemFire 2.0.6, Spring 5.0.5, Spring Boot 2.0.1 used in the project.
It turns out, you did not do anything wrong. Unfortunately, you stumbled across a bug(!), for which I have already filed SGF-747 and fixed. I am sorry for the inconvenience this issue may have caused you.
We are planning a Spring Data Lovelace M3 (Milestone 3) release tomorrow (Thursday, 5/17, CET). The release schedule is visible from Spring Release Calendar. All dates are tentative.
As such, you could try the new Spring Data for Pivotal GemFire (SDG) Lovelace bits (i.e. 2.1.0.M3) with the fix. SDG 2.1.0. should work just fine with Spring Boot 2.0.1/2.RELEASE and Spring 5.0.5/6.RELEASE.
However, if you are expecting to get GA bits for SDG containing this fix, then you will have to wait for the next Spring Data Kay Service Release (Kay SR8), or the Spring Data for Pivotal GemFire 2.0.8 Service Release. I am backing porting this fix.
Unfortunately, there is not another Spring Data Kay Service Release (i.e. Kay SR8) planned until probably around July 2nd or 3rd, right after Spring Framework 5.0.7 is released on Monday, July 2nd and just before Spring Boot 2.0.3 is released on Wednesday, July 4th, which is usually when we plan Spring Data Service Releases. Also, know that Spring Boot 2.0.x is based on Spring Data Kay, but should work just fine with SD Lovelace too, as I mentioned previously.
In the meantime, I will try to think of workaround where the convenience of the Annotations (e.g. #EnableEntityDefinedRegions) can still be used. I will post the workaround in SGF-747.
I see that you specified the clientRegionShortcut attribute in the #EnableCachingDefinedRegions annotation but have declared your application to be a #PeerCacheApplication. While there is no harm in doing so, the clientRegionShortcut attribute is useless in this case. Likewise, the serverRegionShortcut attribute would have no meaning if you are application were a #ClientCacheApplication instead; something to keep in mind.
Lastly, I wanted to let you know that the SDG #EnableStatistics annotation does not have the effect you probably think it does.
Specifically, SDG's #EnableStatistics annotation is concerned with enabling Pivotal GemFire's statistics "sampling" as explained here, which is configured by doing this, as also explained in the SDG #EnableStatistics annotation Javadoc, as well as referenced in the SDG Reference Guide.
The "statistics enabling" that ultimately needs to happen is by setting the Region's staticsEnabled attribute property when configuring and creating the Region (e.g. "blockedIPCache").
That is exactly what the #EnableExpiration annotation will indirectly guarantee now, with the fix in SGF-747, without the need to #EnableStatistics.
Anyway, I hope this all makes sense and helps.
Regards,
John
Does liferay 6.2 allow using new Java 8 date classes such as LocalDate to be used as a datatype for entity column fields,in order to utilise more features on the same.We need to use
<column name="createDate" type="LocalDate" />
instead of<column name="createDate" type="Date" />
Is there some other means to achieve this?Does tweaking hibernate version,allow usage on the same,if so,is that valid?
Liferay 6.2 started with Java 7 compatibility and only got compatible with Java 8 later, mostly due to limitations of the supported application servers - this is a good indicator that there's nothing foreseen with regards to Java 8 classes. While they might work, you might run into untested territory. I'm neither saying it does nor it doesn't - although I suspect that you have tried already and ran into problems when you ask the question here.
As Guivani Grifante said, upgrading Hibernate within Liferay most likely will result in a huge mess, and if you are ready to do that, I'd rather ask to upgrade to Liferay 7 (though I didn't double-check its Hibernate version).
Another means to get to such an adoption is to use the old Date type and just add a converting getLocalDate() and setLocalDate() to the YourModelImpl and just implement the conversion yourself. Yes, a bit weird, but might be the quickest fix, without a lot of immediate upgrade hassle. However, if you use 6.2 CE, note that there won't be any more updates and you should move on to 7 sooner rather than later. If you're on EE, you'll have a while of support left.
This isn't the only problem if you deploy a portlet with Java 8 into Liferay. If your code was compiled with Java 8 and contains remote services generated by service builder, you will get an error while deploy such portlet. This is caused because Liferay uses a Jodd api to analyze bytecode and get the parameters names to show in /api/jsonws
Hibernate 5.x has support to new date api, however, there is little chance of upgrade without break Liferay 6.2.
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.
In my previous spring projects, I always use hibernate+postgresql to store the data. I rencently start to use spring-boot, and I am looking for a database system which allow me embed it in my project, without be required the installation of a external DBMS.
I try use SQLite, but in my searches I found some afirmations Hibernate isn't compatible with SQLite.
Anyone knows if this is possible and could point me a solution?
We've successfuly used HSQLDB with Hibernate for ages.
This is actually super cool for sales, you can demonstrate a working application on (potential) customers machine with the embedded HSQLDB database. And still be able to switch to "the real thing" later on.
See also this:
Does Hibernate Fully Support SQLite
and this:
https://code.google.com/p/hibernate-sqlite/
i'm at my new job and the projects at work are in spring 2.5 (some portlets). how hard is it to migrate to spring 3 ?
there is a customized portal 1.0 (don't know if this is relevant) and i was wondering if i could just ask to develop in spring 3.
never used spring before and want to learn some, but it would be nice if i could just go for the latest version. got spring in action 3rd edition and would like to make use of that
It principle, it should be a drop-in replacement. There's a bunch of stuff that was deprecated in Spring 3, and huge amount of new stuff added, but nothing was removed.
However, there were a bunch of minor bug fixes, and your code may be unwittingly relying on the buggy behaviour, so some minor adjustments may be necessary, but nothing any worse than that.
Other than that, the big difference is that Spring 3 requires Java5+. I'm assuming you're not stuck on 1.4 :)