Proxying the Session: a requirement ?
by Sanne Grinovero
It turns out that using Bridger to restore backwards binary
compatibility will make the Session un-proxable.
Specifically any code attempint to invoke something like:
Session wrapped = (Session) Proxy.newProxyInstance(
Session.class.getClassLoader(),
new Class[] { Session.class }
wrapper
);
will fail at runtime, as the JDK Proxy utility can't deal with bridge methods.
We do proxy the Session in some of our own code - which is of course
something that could be resolved with alternatives - but I wonder if
this approach will break many more frameworks and tools I'm not aware
of.
What do you all think, is this a deal breaker? I'm starting to think
the cure is worse than the disease :/
Thanks,
Sanne
6 years, 10 months
CI Updates
by Davide D'Alto
I'm going to run some updates on CI this Friday.
Cheers,
Davide
6 years, 10 months
Travis build being very unstable with ORM
by Guillaume Smet
Hi,
I don't know if it's an issue you had before with our CI but the Travis
builds are very unstable, failing with this message:
:hibernate-core:testPicked up _JAVA_OPTIONS: -Xmx2048m -Xms512m
No output has been received in the last 10m0s, this potentially indicates a
stalled build or something wrong with the build itself.
Just got 3 in a row...
Moreover the only time I got a build to finish, the build was really really
long.
Wondering if it's such an improvement to base the PR testing on Travis for
ORM.
WDYT?
--
Guillaume
6 years, 10 months
Is unidirectional one-to-one referencing a non-primary key valid
by Gail Badner
Hi,
This is an unusual mapping. My gut feeling is that it is not a valid
mapping, but I don't see anything in the spec that would indicate it is
invalid.
Here is the mapping:
@Entity
public class Product {
@Id
@Column(name = "id")
private int id;
@OneToOne(cascade = CascadeType.ALL)
@JoinColumn(name = "id", referencedColumnName = "productId",
insertable = false, updatable = false)
private ProductInfo productInfo;
}
@Entity
public class ProductInfo{
@Id
private int id;
@Column(name = "productId", unique = true, updatable = false)
private int productId;
}
Hibernate ignores referencedColumnName = "productId" and assumes that
Product and ProductInfo share the same ID value.
When the IDs are not the same, Product#productInfo will be null.
It seem to me that the foreign key column should be
ProductInfo#productId and should reference Product#id, but this
doesn't make sense
for a unidirectional one-to-one owned by Product.
IMO, a bidirectional @OneToOne with ProductInfo owning the association
would make more sense.
A test case can be found at [1]
Is the mapping invalid, or is this a bug in Hibernate?
Thanks,
Gail
[1] https://github.com/gbadner/hibernate-test-case-templates/commit/d806d4ef5...
6 years, 10 months
Self sanity check - caching and stats changes - invalidated query cache results
by Steve Ebersole
I am trying to finish up these caching and stats related changes, but am
currently fighting a few remaining test failures. In my initial
investigation IMO some of these tests are wrong, but hoped someone(s) else
could check may expectation/belief. E.g. have a look at
`org.hibernate.test.querycache.QueryCacheTest#testQueryCacheInvalidation`.
It seems to me that the assertions using stats regarding cache hit/miss/put
counts are wrong right from the very beginning.
But I was hoping to get to a point where absolutely zero test changes were
necessary. So was hoping to get others opinions.
The test issues a number of cacheable queries. The first time happens in a
Session in which the just queried entity is then inserted. This insertion
ought to (validly) trigger an invalidation of these already cached query
results. However the test assertions assert the opposite - that the
insertion not invalidate the cache. Possibly the old code handle this
specially (cache hit + "invalidated results") - I still need to dig into
the old code to see if that is true. But to me, anyway, that seems wrong.
Unless we add a new stat collection for query caching for the number of
times we also considered cached results invalidated due to "update
timestamps".
WDYT?
6 years, 10 months
