Upgrade version of Hibernate - default_schema specificity
by Margot PIVA
Hello,
For the need of our project we had to upgrade the version of
Hibernate from 5.1.2.Final to 5.2.10.Final.
We referred to the changelog
to adapt our code and it worked perfectly well except that
Hibernate
couldn't find our schema event though it was declared on the
search_path of our PostgreSQL database
configuration (at user's level).
We observed that this behavior appeared from (and including) the version
5.1.4.Final,
and we supposed that it came from this bugfix :
https://hibernate.atlassian.net/browse/HHH-11023
Finally we found out
that we had to specify the default_schema directly to Hibernate and we
thought
that it would be favourable to point this necessity out.
8 years, 8 months
SqlTypeDescriptor bind by name limitation
by Vlad Mihalcea
Hi,
While writing an example for a custom Hibernate Type which supports
PostgreSQL arrays,
I realized that the SqlTypeDescriptor only supports bind by name:
@Override
protected void doBind(CallableStatement st, X value, String name,
WrapperOptions options)
throws SQLException {
}
However, for the java.sql.Array, we only have a bind by index method in
java.sql.Statement:
void setArray (int parameterIndex, Array x) throws SQLException;
I remember that 6.0 is going to bind by index, so maybe this issue is
already taken care of in the new version.
Should we provide some fix for 5.x as well?
Vlad
8 years, 8 months
Let's avoid @hsearch.experimental javadoc tags in SPI
by Sanne Grinovero
== SPI have very long guarantees, anyway
Considering that an SPI contract has relatively low SLAs I'd like to
be way more "aggressive" in the removal of "this is experimental"
notices.
I'd also ask you all to consider not marking them as such, especially
if the issue at hand feels properly sorted out.
Most typically we'll have a notice like "This contract is currently
under active development ".
Anything which is marked as such and yet has not changed since the
last minor release should no longer qualify as "active development",
so we should clean it up and avoid scaring away potential users for no
reason.
WDYT?
== What about API ?
I am going to propose cleaning up the "experimental" tag from some
selected APIs as well, yet in that case I don't think we should apply
a similar reasoning as SPI (development activity) as time is not the
right indicator.
Some API has been marked experimental for a long time for good
reasons: we might not have had the bandwidth (or interest) of
finishing some related issue which could be essential for the feature
to be actually used, and it might be problematic to fix such an half
baked feature w/o being ale to make changes in the contract.
== Reminder on changes
Since we're on the subject... the API/SPI/impl classification is not
black and white so bear in mind that any change we make will annoy
someone.
It's a tradeoff, but when you're making *any* change and have the
opportunity to keep the contract backwards compatible, consider doing
so. @Deprecated is a nice annotation.
Of course this is not a reaction on any specific change; if any I'm
just uncomfortable that I'm going to break a lot myself, and my own
experience is that one can deal with some limited amount of
compilation|compatibility issues but if we push too many "SPI & SPI-
changes" in a single release people will get stuck on the older
versions.
We need to enable people to iterate in smaller milestones which are
simpler to handle; if we're doing too much let's just make more
intermediate minor releases.
Thanks!
Sanne
8 years, 8 months
