Gradle not running some unit tests
by Etienne Miret
Hello all,
Willing to investigate some Hibernate bugs, I downloaded the sources (from github), compiled them and ran unit tests. I used the provided Gradle wrapper to compile and run the tests. However, hibernate-core/target/reports/tests/index.html reports a number of test classes as not containing any tests. I mainly looked at org.hibernate.test.cut.CompositeUserTypeTest, and I can tell that:
* it contains two method annotated with @org.junit.Test
* it extends org.hibernate.testing.junit4.BaseUnitTestCase
(through BaseCoreFunctionalTestCase), which has a
@org.junit.runner.RunWith annotation.
>From what I know of Gradle, this is enough to have the tests detected and ran. And actually, those tests *are* detected and ran on branch 4.2. But on branch master, this test class appears in the report with 0 tests within.
Does anyone know why those tests are missing from the report?
In case this is of any help, here is the output of ./gradle --version:
------------------------------------------------------------
Gradle 1.9
------------------------------------------------------------
Build time: 2013-11-19 08:20:02 UTC
Build number: none
Revision: 7970ec3503b4f5767ee1c1c69f8b4186c4763e3d
Groovy: 1.8.6
Ant: Apache Ant(TM) version 1.9.2 compiled on July 8 2013
Ivy: 2.2.0
JVM: 1.7.0_60 (Oracle Corporation 24.60-b09)
OS: Mac OS X 10.9.4 x86_64
Regards,
--
Etienne Miret
12 years, 1 month
JPQL versus HQL
by Etienne Miret
Hello all,
Is HQL a superset of JPQL or a completely different language?
I’m asking because I’m currently adding JPAQL constructions to HQL (see HHH-9342 and HHH-9345), and I want to be sure it is the right thing to do.
Since the reference documentation doesn’t say anything about JPQL, I suspect the former (HQL superset of JPQL), but I’d like to be sure.
Regards,
--
Etienne Miret
12 years, 1 month
New disruptive API possibilities in Java8: what do we do?
by Sanne Grinovero
As in this forum post:
- https://forum.hibernate.org/viewtopic.php?f=1&t=1036010
and some conversations I catched on the twitter radar, SO and other
posts, lots of people are wondering what our "amazing plans" are
around powerful innovations we could to thanks to Java8.
I understand we're all quite stretched and I don't think I can take
the lead on this either, but I think we should at least provide
potential contributors with some options to experiment and see where
we can get.
As soon as we have confluence we could have a page to describe our
constraints and possibly to collect nice ideas. Beyond that, what
about having some kind of sandbox project for an ORM wrapper (and
maybe others) to play with experimental API proposals?
I would love to be able to suggest some "get prototyping here" plan to
smart proposals like the one in this forum post.
--Sanne
12 years, 1 month
Exposing Hibernate statistics via JMX
by Gunnar Morling
Steve, all,
I've been asked about the Hibernate statistics functionality which used to
be accessible via JMX.
There used to be StatisticsService which was an MBean and which one could
register with the JMX platform. This has been removed a while ago, and
there is the related issue HHH-6190 which still is open.
Until this is resolved, what is the recommended strategy towards making the
statistics available via JMX? Should users create and export their own
MBean based on SessionFactory#getStatistics()? Or is there any other
replacement for StatisticsService?
Thanks,
--Gunnar
[1] https://hibernate.atlassian.net/browse/HHH-6190
12 years, 1 month
Re: [hibernate-dev] [Search] @Transformable vs @ProvidedId
by Sanne Grinovero
There is an additional complex choice to make.
Considering that Infinispan has this separate notion of Key vs Value, and
both have to contribute to building the final indexed Document, why is it
that we allow the decision of which index is being targeted to be made by
*the type of the value*?
I think the index definition belongs as a responsibility to the *type of
the identifier*, the value should at most help to identify a shard among
the ones identified by its key.
!!! ->
We might want to consider imposing a hard limitation of not allowing a
single index to be shared across multiple key types. This implies the
@Indexed annotation and its other key options should be defined on the
keys, not the values.
If we did that, it wouldn't matter if the index is defined on the key or on
the value as there would be a 1:1 possible combination.
Does anyone see this as a strong limitation or usability concern?
This would also resolve a couple of performance problems.
Beyond this, considering it's valid (and sometimes useful) to store
PersonFile p = ...
cache.put( p.taxcode, p );
cache.put( p.uniquename, p );
As a user I think I might even want to define an alternative index mapping
for PersonFile, depending on if it's being stored by uniquename or by
taxcode.
That's totally doable with the Search engine, but how do you envision the
user to define this mapping? He can't use annotations on PersonFile, so the
user needs to be able to register some form of programmatic mapping linked
to the different key types.
There is an additional flaw, which is that I'm implying that taxcode and
uniquname are of a different type: otherwise we couldn't distinguish the
two different meanings of the two put operations. This is generally a fair
assumption as you wouldn't want to have key collisions if you're storing in
such a fashion, but there might be a known business rule for which such a
collision is impossible (i.e. the two codes having a different format). So
while you probably shouldn't do this in a strong domain, it's a legal usage
of the Cache API.
Considering these pitfalls I think I have successfully convinced myself
that we should not allow for a different mapping for the same type of key.
Question remains if it's more correct to bind the index identification (the
name) to the key type.
@Hardy yes I will need the Infinispan team's thoughts too, but don't feel
excluded, there aren't many smart engineers around knowing about the
Infinispan/Query usage :)
Cheers,
Sanne
On 7 August 2014 22:50, Hardy Ferentschik <hardy(a)hibernate.org> wrote:
>
> On 7 Jan 2014, at 23:42, Sanne Grinovero <sanne(a)hibernate.org> wrote:
>
> >
> >
> >
> > On 7 August 2014 22:37, Hardy Ferentschik <hardy(a)hibernate.org> wrote:
> >
> > On 7 Jan 2014, at 19:56, Sanne Grinovero <sanne(a)hibernate.org> wrote:
> >
> > > I was hoping to drop @ProvidedId today as the original "marker"
> > > functionality is no longer needed: since we have
> > >
> > >
> org.hibernate.search.cfg.spi.SearchConfiguration.isIdProvidedImplicit()
> > >
> > > the option can be implicitly applied to all indexed entries, and the
> > > annotation is mostly redundant in Infinispan since we added this.
> > >
> > > But actually it turns out it's a bit more complex as it servers a
> second
> > > function as well: it's the only way for users to be able to specify a
> > > FieldBridge for the ID.. so the functionality of this annotation is not
> > > consumed yet.
> >
> > Wouldn’t an additional explicit @FieldBridge annotation work as well?
> >
> > Yes! But we'd need to apply it to the key type.
> > This implies changing it to allow target @Target(TYPE), which doesn't
> make much sense for our ORM users, but also the name "FieldBridge" is
> rather odd to be applied on a type and not a field.
>
> Fair enough. I also know too little about the Infinispan usage of Search
> in this case.
> Either way, @ProvidedId should go, at least from a pure Search point of
> view.
>
> —Hardy
>
>
12 years, 1 month
Re: [hibernate-dev] [Search] @Transformable vs @ProvidedId
by Sanne Grinovero
On 7 August 2014 22:37, Hardy Ferentschik <hardy(a)hibernate.org> wrote:
>
> On 7 Jan 2014, at 19:56, Sanne Grinovero <sanne(a)hibernate.org> wrote:
>
> > I was hoping to drop @ProvidedId today as the original "marker"
> > functionality is no longer needed: since we have
> >
> > org.hibernate.search.cfg.spi.SearchConfiguration.isIdProvidedImplicit()
> >
> > the option can be implicitly applied to all indexed entries, and the
> > annotation is mostly redundant in Infinispan since we added this.
> >
> > But actually it turns out it's a bit more complex as it servers a second
> > function as well: it's the only way for users to be able to specify a
> > FieldBridge for the ID.. so the functionality of this annotation is not
> > consumed yet.
>
> Wouldn’t an additional explicit @FieldBridge annotation work as well?
>
Yes! But we'd need to apply it to the key type.
This implies changing it to allow target @Target(TYPE), which doesn't make
much sense for our ORM users, but also the name "FieldBridge" is rather odd
to be applied on a type and not a field.
12 years, 1 month
JdbcSession proposal
by Steve Ebersole
I found a few spare minutes to work on this a little and move it into
the next stage with some actual interfaces, impls and usages to help
illustrate some of the proposed concepts.
https://github.com/sebersole/JdbcSession
The README.md is very up-to-date and detailed. Would be good to get
input from others.
P.S. I probably dislike the *Inflow naming more than you do :)
12 years, 1 month
