Google Summer of Code 2015
by Martin Braun
Hi there,
I am happy to announce that I will be participating in this years Google Summer of Code working on Hibernate Search.
My project's goal is to make Hibernate Search able to work with other JPA implementors than Hibernate ORM. I have written
a short introduction about me and the project on my blog:
http://hibernatesearchandjpa.blogspot.de/
I am really looking forward to working with you all and please let me know about your thoughts on this project! :)
mfg
Martin Braun
martinbraun123(a)aol.com
www.github.com/s4ke
10 years, 5 months
Any change of adding generics to Hibernate specific API
by Mihalcea Vlad
Hi,
Although many rely on the Java Persistence API, Hibernate still offers specific features, like mapping a native SQLQuery result set to a DTO:
.setResultTransformer(Transformers.aliasToBean(DTO.class));
Is it possible to add TypedQuery and TypedSQLQuery, analogous to the JPA specs, so you can use generics with specific API?
Adding new interfaces and some overloaded Session methods wouldn't break backward compatibility.
Vlad MiIhalcea
10 years, 6 months
Keeping context in the scope of a transaction
by Gunnar Morling
Steve, Andrea,
For OGM we need to store certain data in the scope of a transaction;
specifically this is the list of applied "grid dialect operations", so we
can present these to the user upon failures (and thus "rollbacks") on
non-transactional backends.
Until now we used a custom org.hibernate.Transaction impl for keeping this
data. I am now looking into using the new TransactionCoordinator approach
instead. Is it a save route to initialise the required context upon first
invocation of MyTransactionCoordinator#getTransactionDriverControl() and
clear it via TransactionObserver#afterCompletion()?
It works fine for me in our tests, but I'd like to make sure I am not
missing anything :)
Thanks,
--Gunnar
10 years, 6 months
Changes around transaction -> changed exception behavior
by Gunnar Morling
Hi,
while working on making OGM work with ORM 5, I noticed a slightly different
behaviour wrt. to exceptions occurring during flushes.
Previously, such exceptions would bubble up as is, whereas now the
beforeTransactionCompletion() logic is called in a try/catch block,
wrapping any exceptions in a TransactionException. It's no big deal for me
(I just need to adapt some tests in our suite which expect specific
exception types), but then I was wondering whether that change poses a
migration issue for existing client code, e.g.
expecting/handling StaleObjectStateException which would need to be adapted
accordingly?
Anyone thinking it's a problem?
Thanks,
--Gunnar
10 years, 6 months
Today's release
by Steve Ebersole
I had originally planned on today's release being the first CR for 5.0. I
am re-thinking that now. Here is why...
1) If we were to ever start offering a typed API, a major major release
would be the time to do that. However, we'd still have the "load() + proxy
interfaces" issue to decide a course of action on.
2) I have just introduced that Transaction changes after the first Beta.
It is probably prudent to have one more Beta to allow people time to try
out those changes and ask for changes.
3) I would still like to complete deprecating the Settings contract. The
last piece there is the discussion I started earlier on the dev list wrt
its usage in SPI contracts (L2 cache, etc). I would likely not get that
done today.
So I wanted to suggest that today's release instead be Beta2, with CR1
slated for 4 weeks from today. Thoughts?
10 years, 6 months
Datomic OGM implementation
by Haswell, Josiah D
Hi folks,
How can I begin to submit a new grid dialect to the project? I'm most of the way through implementing a dialect for Datomic<http://www.datomic.com/>, and am most of the way through the approval process to submit it back to the community. I've had to make some (pretty minor) changes to
Hibernate-ogm-core that I'd like feedback on, as well. Do I just submit a pull request?
Thanks!
Josiah Haswell
10 years, 6 months
org.hibernate.cfg.Settings deprecated
by Steve Ebersole
Last night I pushed some changes which included deprecating
org.hibernate.cfg.Settings in favor
of org.hibernate.boot.spi.SessionFactoryOptions. The main reason for this
was to make it easier for OGM and others to hook into the SessionFactory
creation process. For now, I have made Settings delegate
to SessionFactoryOptions.
I am not sure if anything external relies on this Settings contract. But
there are a few usages I wanted to discuss.
First is caching. Part of the SPI for building RegionFactrory is passing
along the Settings object. Ideally I'd just swap this with
SessionFactoryOptions. And given that this targets a major release (5.0),
that should be ok. Anyone against that? Sanne? Galder? Alex?
Second is the initiation of BV integration. The TypesafeActivator accesses
the Settings object in order to
call org.hibernate.cfg.Settings#setCheckNullability. As of now, this is
the only setter method I have left on Settings (it simply passes that call
on to the SessionFactoryOptions, which exposes just this one setter for
just this one case). I'd like to make it so that SessionFactoryOptions is
immutable at the time SessionFactory is built. This was largely true for
Settings already aside from this one use case. I am just not sure yet of
the best way to allow an Integrator to affect this SessionFactoryBuilder
process. Thoughts?
10 years, 6 months
Quick question about PostCommitInsertEventListener
by Haswell, Josiah D
Hi folks,
In Datomic, when you create an entity, you must give the entity a temporary ID before you insert it. After the transaction completes, each entity in the transaction is given an actual persistence ID back from the database. My initial approach was to generate the temporary identifier in the createTuple method of the IdentityColumnAwareGridDialect, and provide a customer persister implementation to handle it. It occurred to me that it might be easier to just use a listener. After a bit of fiddling around, I discovered that PostCommitInsertEventListener can (apparently) substitute out the ID at what appears to be the correct location. From what I can tell, this both simplifies the code, and the generated ID seems to be propagated to everything correctly. Is the custom persister the preferred way to do this? Or should this work? Is there a better place to perform that substitution?
Thanks!
Josiah
10 years, 6 months
