4.3
by Steve Ebersole
I am having trouble building 4.3 even from a clean checkout:
:hibernate-core:runSourceGenerators
:hibernate-core:runAnnotationProcessors FAILED
FAILURE: Build failed with an exception.
* Where:
Script
'/home/sebersole/projects/hibernate/hibernate-4.3/hibernate-orm/source-generation.gradle'
line: 305
8 years, 11 months
Upgrades for ci.hibernate.org
by Sanne Grinovero
Hi all,
the build slaves for ci.hibernate.org got refreshed.
Several jobs failed during the last week as the micro quotas we had
were getting full.
The 4 nodes have now 4 times the RAM, 4 times the CPU and 8 times the
disk space.
(that's 15GB of RAM, 8 CPUs, 80GB of dedicated space per node)
N.B. both relational and NoSQL databases are running on a much smaller
18GB partition, shared with the OS system files. Tests are expected to
cleanup after use!
I've tested some of the main builds and they seem to run fine, but
there are various exotic jobs which don't get run too often.. please
let us know if you see something unusual.
Some things of note:
- I reconfigured the Gradle and Maven global environment (defaults)
to more generous heap sizes
-- you might want to do the same, if you did override those in your jobs
- the various JDKs got updated
- the HQL Parser project apparently was just verifying it could
successfully checkout the project.. fixed that to actually run the
build, and the tests too!
- it took Davide and me a couple of hours to figure how to script the
disk size changes, but the actual re-build from scratch of all slaves
only took minutes! eureka
- the HQL Parser is now experimenting with the Gradle option to run
parallel builds (try to get some benefits form all these cores)
-- I'm temporarily playing with the setting on Hibernate ORM too,
I'll probably return it to more conservative options soon ..
Remaining TODOs:
- merge the open PRs of ci.hibernate.org
- think of how to automate disk space reclaim? Or keep an eye on its growth
- Several Jenkins plugins need to be upgraded. I'd prefer we wait a
bit on that and verify first that most jobs build fine, to ease
diagnostics of all the things which break when those get updated..
Thanks,
Sanne
8 years, 11 months
Support for DELETE statements ActionQueue sorting
by Mihalcea Vlad
Hi,
While INSERT sorting is handled by ActionQueue.InsertActionSorter, DELETE statements are not sorted at all.
A DeleteActionSorter woudl have to rearrange DELETES in the opposite order as the INSERT sorting, the Children having to be deleted first.
The current work-around is to dissociate all Children and manually flush the Session, so that the orphan-removal kicks in before the Parent entities delete occurs.
Any plans for supporting such a feature?
Vlad Mihalcea
8 years, 11 months
[Search] Projections of collection of elements with embeddable
by Davide D'Alto
Hi,
while working on OGM-781 I noticed that there is a problem with Hibernate
Search when trying to get the projection of a property that represents a
collection of elements..
EntityInfo#getProjections()[0] will always return the first value of the
association.
For example, if I index the following entity:
@Indexed
public static class ExampleEntity {
@Field(store = Store.YES)
Integer someInteger;
...
@Field(store = Store.YES)
@IndexedEmbedded
List<Integer> someCollection;
}
and than add a projection on "someCollection"
EntityInfo.getProjection()[0] will only return the first result of the
collection instead of returning a List<Integer>.
This seems a bug to me.
I've already created a local branch that should fix the behaviour in this
case.
It also makes me wonder, what should we do with a list of embeddables?
For example:
@Field(store = Store.YES)
@IndexedEmbedded
List<ExampleEntity> nestedExamples
In this case, would it make sense to project "someCollection.someInteger"?
And what would be the expected result calling EntityInfo.getProjection()[0]?
Cheers,
Davide
8 years, 11 months
ORM - FindBugs/PMD
by Steve Ebersole
Checkstyle in ORM is now good to go and enforced in the CI jobs.
So I started thinking about FindBugs. We do have FindBugs set up. However
it is utterly out of control at the moment. Maybe it's just me, but I find
FindBugs impossible to configure "well". Granted I have little experience
with it, but Web searches turn up almost nothing on how to configure
FindBugs. A few things in particular bug me about FindBugs:
1) Because it works on classes, not sources, it's nearly impossible to
succinctly say "ignore generated sources". Would love to be proved wrong
there :)
2) I am unsure how to tell FindBugs which rules to run and which to not. I
*think* this can be done through its filter files, but I have yet to find a
decent doc on doing that.
3) I have no idea how to change the confidence and severity of the things
FindBugs reports. I have mentioned the DM_CONVERT_CASE scenario to some of
you before. For us that is always a bug but FindBugs treats it with low
confidence (maybe a bug, maybe not).
I know PMD covers a lot of the same cases. Anyone familiar with it? lf it
is more easily configurable, maybe it fits our needs better...
8 years, 11 months
Sharing IDE code styles
by Steve Ebersole
The recent discussion on Checkstyle got me thinking about best ways to
share/distribute code styles for IDE setup. Storing them in the project
itself is not very workable for IntelliJ at least. I started thinking
about a separate repository under the hibernate GitHub organization. Does
everyone use the code style I attached to
https://developer.jboss.org/wiki/ContributingToHibernateUsingIntelliJ, or
do y'all use custom versions of that?
Do y'all think it makes any sense to do this?
8 years, 11 months
Hibernate O/RM Java 8 API.
by Jakub Narloch
Hi,
I would like to get back to last year idea, namely the the idea to
introduce new Java 8 API. Since that would not be possible to do directly
in Hibernate Core since it's backward compatibility with Java 6, I had
created a side project that introduces decorator/wrapper on top of
Hibernate Query API that introduces support for Streams<?> and retrieving
Optional<?> results.
I had already implemented the two basic ideas and was hopping for some kind
of feedback whether you would be interested in continouing this idea, also
a code review would be a usefull thing.
References:
Github project: https://github.com/jmnarloch/hibernate-streams-wrapper
JIRA issue: https://hibernate.atlassian.net/browse/HHH-9338
Regards,
Jakub Narloch
8 years, 11 months
Checkstyle and ORM
by Steve Ebersole
FYI : https://hibernate.atlassian.net/browse/HHH-9803
Its not super high on my priority list, but I want to get to a point where
we can start to fail the build on "serious checkstyle regressions". Part
of that is being more realistic with what is considered serious, and part
of that is fixing up code.
For example, we have quite a few warnings about spaces rather than tabs for
indentation. That's a serious one to me. There are quite a few "unused
import" warnings, again to me that's serious (it just looks sloppy).
A few I have already disabled. Checking that there is a package-info.java
file for example. I'd love to make a requirement that all API and SPI
packages have one. But as far as I know that detailing is not available in
checkstyle, and I really dont overly care about package-info.java files for
internal packages.
These are just a few examples. #909[1] (still running atm) is the first
build with my preliminary work here. Let me know if there are any checks
anyone feels strongly about in one bucket or another.
[1] http://ci.hibernate.org/job/hibernate-orm-master-h2/909/
8 years, 11 months
[ORM|OGM|Search] Adding an unwrap() new method to org.hibernate.Session
by Sanne Grinovero
I was looking at how Search and OGM benefit from the
SessionDelegatorBaseImpl; extending this base class was a good
progress but there is something missing.
OGM has to still reimplement all methods defined by the EventSource
contract, making the implementation confusing as while it extends the
base delegate it still has to directly delegate for many other
methods.
So my initial impulse was to go and refactor the
SessionDelegatorBaseImpl to actually be an "EventSourceBaseDelegator",
adding the additional interface and delegates for the missing methods.
But questioning why the OGM Session needs to implement EventSource, it
turns out the reason is that when it uses Search this needs to access
the EventSource and will cast the given Session to one; so OGM's
Session has to implement that interface too, only for this reason.
Such a cast has never been dangerous for Search in the past as there
was only one Session but the existence of the SessionDelegatorBaseImpl
in ORM is making it easy to see more Session implementations which
actually don't implement EventSource (and often don't need to).
Rather than forcing / recommending all implementors to consistently
extend EventSource as well, it would be nice to introduce a way to get
a typesafe reference to the only EventSource we need.
My proposal is to add an unwrap() method to the public
org.hibernate.Session, like the one in JPA, and enhance the
implementation of both SessionImpl#unwrap and the
EntityManagerImpl#unwrap() to also satisfy requests for the
EventSource.class, and then possibly other such components as needed.
I would then be able to remove some casts in various places, and OGM's
Session wouldn't need to implement the EventSource interface.
ok?
Thanks,
Sanne
8 years, 11 months
