API differences in Hibernate ORM 5.1 vs 5.3
by Gail Badner
Hi,
There were lots of differences in the compatibility report, so as a first
step, I've excluded packages/classes that I considered SPI, internal, or
"grey area". This reduced the the differences to a more manageable amount.
You can see a summary of the incompatibilities along with suggested
mitigation at [1].
The report is attached to [1], along with a zip with instructions for
running the report.
I believe there are some "false positives" in the report, and I have
documented them in the section, "False Positives?".
Feel free to comment on the article.
Thanks,
Gail
[1]
https://developer.jboss.org/wiki/HibernateORMBinaryCompatibilityBetween51...
5 days, 6 hours
IP banned from forum
by Gunnar Morling
Hi,
Is anyone banning users from the forum? I am getting "A ban has been
issued on your IP address."
I don't think banning by IP is a good strategy as many users will have
dynamic IPs from their hoster's shared pool, so it's a random game to
hit an IP previously banned due to some other user's spam.
Thanks,
--Gunnar
5 days, 13 hours
New CI machine preview
by Sanne Grinovero
You're all welcome to play with http://54.225.162.168/
however please keep these in mind:
- it's not the final machine: don't put too much effort in creating
nice build scripts as we'll reset it to clean state soon. We *might*
be able to store jobs defined so far, but we might choose not to.
- domain name should be coming: ci.hibernate.org ..not sure when, got
no replies so far from.
- authentication: just click on login, it will use OAuth2 to request
your identity via your GitHub account. Permissions to create new jobs,
edit existing jobs, run a build manually depend on your github account
be part of the Hibernate organization (or not, in which case you have
read only status)
At this stage I'd like to get a feeling if the hardware is powerful
enough, and also we need to select which other plugins we want to use,
I'm looking especially to:
- static analysis reports
- pull requests integration
both are relatively undefined, we can of course start simple and
improve later.. just checking this fits basic needs now.
Sanne
2 months, 2 weeks
Stride
by Steve Ebersole
I got an email from Atlassian this morning about the migration from HipChat
to Stride. Basically they have not gotten Stride feature-complete in terms
of HipChat which is the trigger for the mass migration. However, they are
reaching out to all waiting teams to see if any want to migrate anyway.
The list of missing features they sent me are:
1. Guest access
2. Some admin controls and compliance settings
3. Integrations with Atlassian server products (the Jira Server app is
currently in beta and coming soon) and some other popular integrations. See
all available Stride integrations
<http://click.mailer.atlassian.com/?qs=6712850cb7a4f2d4a207f46e5f190a45485...>
.
4. User management via API
5. Dark mode
I am not really sure exactly what is missing WRT (2). (3) is nice-to-have,
but not blocker IMO assuming it gets added at some point.
I think (1) is the only one that is concerning. Though TBH for myself
personally, I do not think registering is a big deal.
Unless I hear otherwise, I plan on asking them to proceed with our
migration to Stride.
7 years, 5 months
AbstractStandardBasicType#getReplacement() prototype is incorrect since HHH-12054
by Guillaume Smet
Hi,
When HHH-12054 was fixed (see
https://github.com/hibernate/hibernate-orm/pull/2042/files), we took into
account the fact that original and target could be set to
LazyPropertyInitializer.UNFETCHED_PROPERTY in the
AbstractStandardBasicType#getReplacement() method whereas we haven't
changed the prototype of the method.
Meaning we expect for instance LazyPropertyInitializer.UNFETCHED_PROPERTY
to be a T, which is not the case.
This led to ClassCastException such as in
https://hibernate.atlassian.net/browse/HHH-12555 . To be honest, I'm
wondering why we don't have more of them.
We have 2 ways of fixing this issue:
1- change the getReplacement() prototype to take Object parameters and
return an Object as the originating replace() method
2- move the LazyPropertyInitializer.UNFETCHED_PROPERTY logic up to
replace() and make getReplacement() a "I'm sure everything is OK, now get
me a clone of my original object" thing.
1- will obviously break compatibility with any user type extending
AbstractStandardBasicType#getReplacement(). 2- will slightly change the
meaning of replace() and getReplacement() and might lead to subtle behavior
changes in user applications.
2- also means that we would have to override both replace() and
getReplacement() in BlobType and allegates.
I pushed a commit for 1- at
https://github.com/gsmet/hibernate-orm/commit/73e66e40f3438794375451145af...
so that you can fully grasp the issue.
Not saying it's the path we should take.
Thoughts?
--
Guillaume
7 years, 6 months
Message could not be delivered
by Bounced mail
The original message was received at Fri, 29 Jun 2018 06:03:38 +0800
from lists.jboss.org [154.188.185.178]
----- The following addresses had permanent fatal errors -----
<hibernate-dev(a)lists.jboss.org>
7 years, 6 months
Provide a RegionFactory from Spring
by Henri Tremblay
Hi,
A change in the latest Spring Boot version is now setting a real class
loader when creating a JCache cache manager. Before it used to pass null.
Just like Hibernate still does.
So right now, we end up with two class managers. One for Hibernate 2nd
level cache and one for Spring cache.
We made a workaround in JHipster. You can see the full code and discussion
here
https://github.com/hibernate/hibernate-orm/pull/2351
It's not super pretty. The Hibernate region factory is instantiated from a
property using the no-args constructor. So we set the wanted class loader
to a static variable and retrieves it in the region factory implementation.
It works. But it's not pretty.
I was looking for a cleaner solution. Probably passing a Contributor to
Hibernate.
Is there a way to programmatically pass a contributor or a region factory
to Hibernate? From Spring Boot.
Thanks,
Henri
7 years, 7 months
Backport caching ValueBinders and ValueExtractors for a SqlTypeDescriptor from 6.0 to 5.x
by Steve Ebersole
Today, when either `SqlTypeDescriptor#getBinder` or
`SqlTypeDescriptor#getExtractor` are called we build/calculate the
binder/extractor each and every time. In 6.0 we added code that caches
these binders and extractors as they are requested.
IMO we should backport the idea of caching these to 5.x. Any volunteers?
The code on 6.0 is still local to my machine, but the code in general looks
like[1]:
public interface SqlTypeDescriptor {
...
<X>JdbcValueMapper<X> getJdbcValueMapper(BasicJavaDescriptor<X>
javaTypeDescriptor);
@Remove
default <X> JdbcValueBinder<X> getBinder(BasicJavaDescriptor<X>
javaTypeDescriptor) {
return getJdbcValueMapper( javaTypeDescriptor ).getJdbcValueBinder();
}
@Remove
default <X> JdbcValueExtractor<X> getExtractor(BasicJavaDescriptor<X>
javaTypeDescriptor) {
return getJdbcValueMapper( javaTypeDescriptor ).getJdbcValueExtractor();
}
}
public abstract class AbstractSqlTypeDescriptor implements
SqlTypeDescriptor {
private final Map<JavaTypeDescriptor<?>,JdbcValueMapper<?>>
valueMapperCache = new ConcurrentHashMap<>();
protected <J> JdbcValueMapper<J> determineValueMapper(
JavaTypeDescriptor<J> javaTypeDescriptor,
Function<JavaTypeDescriptor<J>,JdbcValueMapper<J>> creator) {
return (JdbcValueMapper<J>) valueMapperCache.computeIfAbsent(
javaTypeDescriptor,
javaTypeDescriptor1 -> creator.apply( javaTypeDescriptor )
);
}
}
public abstract class AbstractTemplateSqlTypeDescriptor extends
AbstractSqlTypeDescriptor {
@Override
public <X> JdbcValueMapper<X> getJdbcValueMapper(BasicJavaDescriptor<X>
javaTypeDescriptor) {
return determineValueMapper(
javaTypeDescriptor,
jtd -> {
final JdbcValueBinder<X> binder = createBinder( javaTypeDescriptor );
final JdbcValueExtractor<X> extractor = createExtractor( javaTypeDescriptor
);
return new JdbcValueMapperImpl<>( javaTypeDescriptor, this, extractor,
binder );
}
);
}
protected abstract <X> JdbcValueBinder<X>
createBinder(BasicJavaDescriptor<X> javaTypeDescriptor);
protected abstract <X> JdbcValueExtractor<X>
createExtractor(BasicJavaDescriptor<X> javaTypeDescriptor);
}
[1] In 6.0 ValueBinder is replaced by JdbcValueBinder and ValueExtractor is
replaced by JdbcValueExtractor - the new variants serve the same basic
purposes but in different ways related to the other changes in 6.0.
JdbcValueMapper is a new contract that combines a JavaTypeDescriptor
(specifically a BasicJavaDescriptor since all JDBC types are "basic"),
SqlTypeDescriptor, JdbcValueBinder and JdbcValueExtractor
7 years, 7 months
