Naming strategies 4.3 -> 5.0
by Steve Ebersole
I think I may have goofed when I implemented some of the
ImplicitNamingStrategy rules in 5.0.
During that transition, I wrote a bunch of unit test in 4.3 to serve as a
baseline to make sure I got the logic/rules right as I developed 5.0. But
I think I may have set up those initial 4.3 tests improperly.
Specifically, there are a few meant to test Hibernate's legacy naming
behavior, aka its non-JPA-compliant naming.
I think I got confused by the whole concept of NamingStrategy and
NamingStrategyDelegate and NamingStrategyDelegator that had gotten added to
4.3.
So on 4.3, what is the proper way to specify Hibernate should use
JPA-compliant implicit naming? What is the proper way to specify that it
should use its legacy naming?
The issue came to light via HHH-9908. Consider a mapping like:
@Entity
@Table(name = "ptx")
public class Ptx {
@Id
private Integer id;
@ManyToMany
private List<Input> inputs1;
}
Assuming that Inputs defines its primary table as "input", the
JPA-compliant naming would be "ptx_input". That is what happens on 4.3
using EJB3NamingStrategy. It is actually also what happens on master using
ImplicitNamingStrategyJpaCompliantImpl.
However, the "legacy" part I cannot figure out. Unless I misremember, back
in the day we used to interpret these based on the attribute name, rather
than the associated table name. So here we'd have "ptx_inputs1". That is
in fact what ImprovedNamingStrategy does on 4.3. But I
believe ImprovedNamingStrategy is not the default on 4.3. Again, between
NamingStrategy and NamingStrategyDelegate and NamingStrategyDelegator it is
VERY hard to understand what it going on, so maybe I just missed
something. Anyway, on 4.3 setting no naming strategy forces this to behave
in a JPA-compliant way, meaning the implicit name here is "ptx_input" when
I do not specify anything for NamingStrategy(Delegat(e/or)). So either
that got screwed up in 4.2/4.3 (whenever those new indirections where
added) or I simply misremember what we used to do here.
8 years, 8 months
Missing transaction hangs the testsuite
by Sanne Grinovero
I finally got to re-enable MariaDB and PostgreSQL based tests for
Hibernate Search - which has been running on H2 only for some months -
and had to debug a case of a single test hanging for a long time.
Essentially it would block - for hours - on the SessionFactory#close()
method, attempting to drop the database schema with the following
statement:
> alter table AncientBook_alternativeTitles drop constraint
FKn8hhkmhof1mdgc4oi77ccq989
Dumping threads I would get a very similar stack trace on both
databases; initially I thought someone had copy/pasted a socket
handling bug from one JDBC driver to the other ;-)
The PostgreSQL testsuite hanging:
"main" prio=10 tid=0x00007f0f40009000 nid=0x5f7c runnable [0x00007f0f48956000]
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:152)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at org.postgresql.core.VisibleBufferedInputStream.readMore(VisibleBufferedInputStream.java:145)
at org.postgresql.core.VisibleBufferedInputStream.ensureBytes(VisibleBufferedInputStream.java:114)
at org.postgresql.core.VisibleBufferedInputStream.read(VisibleBufferedInputStream.java:73)
at org.postgresql.core.PGStream.ReceiveChar(PGStream.java:274)
at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1660)
at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:257)
- locked <0x00000007c11e3860> (a org.postgresql.core.v3.QueryExecutorImpl)
at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:500)
at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:374)
at org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(AbstractJdbc2Statement.java:302)
at org.hibernate.tool.hbm2ddl.DatabaseExporter.export(DatabaseExporter.java:47)
at org.hibernate.tool.hbm2ddl.SchemaExport.perform(SchemaExport.java:476)
at org.hibernate.tool.hbm2ddl.SchemaExport.execute(SchemaExport.java:430)
at org.hibernate.tool.hbm2ddl.SchemaExport.drop(SchemaExport.java:375)
at org.hibernate.tool.hbm2ddl.SchemaExport.drop(SchemaExport.java:371)
at org.hibernate.internal.SessionFactoryImpl.close(SessionFactoryImpl.java:1069)
at org.hibernate.search.test.util.FullTextSessionBuilder.close(FullTextSessionBuilder.java:149)
at org.hibernate.search.test.util.FullTextSessionBuilder$1.evaluate(FullTextSessionBuilder.java:248)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
The MariaDB testsuite hanging:
"main" prio=10 tid=0x00007f8ca0009000 nid=0x4043 runnable [0x00007f8ca5f5c000]
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:152)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at com.mysql.jdbc.util.ReadAheadInputStream.fill(ReadAheadInputStream.java:114)
at com.mysql.jdbc.util.ReadAheadInputStream.readFromUnderlyingStreamIfNecessary(ReadAheadInputStream.java:161)
at com.mysql.jdbc.util.ReadAheadInputStream.read(ReadAheadInputStream.java:189)
- locked <0x00000007c0baa518> (a com.mysql.jdbc.util.ReadAheadInputStream)
at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:2499)
at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2952)
at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2941)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3489)
at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1959)
at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2113)
at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2562)
- locked <0x00000007c0baa850> (a java.lang.Object)
at com.mysql.jdbc.StatementImpl.executeUpdate(StatementImpl.java:1664)
- locked <0x00000007c0baa850> (a java.lang.Object)
at com.mysql.jdbc.StatementImpl.executeUpdate(StatementImpl.java:1583)
at org.hibernate.tool.hbm2ddl.DatabaseExporter.export(DatabaseExporter.java:47)
at org.hibernate.tool.hbm2ddl.SchemaExport.perform(SchemaExport.java:476)
at org.hibernate.tool.hbm2ddl.SchemaExport.execute(SchemaExport.java:430)
at org.hibernate.tool.hbm2ddl.SchemaExport.drop(SchemaExport.java:375)
at org.hibernate.tool.hbm2ddl.SchemaExport.drop(SchemaExport.java:371)
at org.hibernate.internal.SessionFactoryImpl.close(SessionFactoryImpl.java:1069)
at org.hibernate.search.test.util.FullTextSessionBuilder.close(FullTextSessionBuilder.java:149)
at org.hibernate.search.test.util.FullTextSessionBuilder$1.evaluate(FullTextSessionBuilder.java:248)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
On Gail's suggestion I went looking for database level locks; I hadn't
thought of that as I assumed it would have timed out more aggressively
rather than have me wait for hours.
It turns out she was right and the reason for blocking was a simple
"count *" query being run as a post-test assertion, which we had
forgotten to wrap in an "open transaction & commit" statements pair.
The test assertion would be successful, but apparently it would hold
on the table lock beyond closing the Session and, then fail to drop
the database at the teardown of the test.
I'm wondering if this is expected, or if there's something in the new
transaction handling code which could be improved? It took me several
hours to figure this out; maybe I'm just not using ORM as frequently
as once :)
If it's this critical to have the transaction, maybe it should be mandatory?
And as a memo for next time, this is the query to figure out details
about locks on our testing db:
> SELECT * FROM pg_locks pl LEFT JOIN pg_stat_activity psa ON pl.pid
= psa.pid where datname = 'testingdb';
Thanks,
Sanne
8 years, 8 months
OGM build job failed: javac bug!
by Sanne Grinovero
I only noticed today that this job is failing:
- http://ci.hibernate.org/job/hibernate-ogm-release/64/console
and so did the previous one (build 63).
The highlight in the logs seems to be
"An exception has occurred in the compiler (1.8.0_45). Please file a
bug at the Java Developer Connection
(http://java.sun.com/webapps/bugreport) after checking the Bug Parade
for duplicates. Include your program and the following diagnostic in
your report. Thank you."
[followed by stacktraces]
Did someone already check that
a) it didn't hose the release
b) if there are duplicates, or we need reporting?
Thanks,
Sanne
8 years, 8 months
Triage
by Steve Ebersole
Sorry, I am not going to be able to make the meeting. But you guys meet if
you want to. I will make next weeks meeting.
8 years, 8 months
[Hibernate Search] DocValues and Sorting API -> new mapping annotations ?
by Sanne Grinovero
You might remember that running a full-text Query on a field always
required some specific care;
since the beginning of Hibernate Search the user had to make sure the
field was not tokenized, or tokenized but generating a single token.
This was a "soft requirement": if you didn't know, you'd get
inconsistent results but no error would be shown - after all, a Lucene
was typically schema-less.
With Lucene 5, if you didn't map your field specifically for the
sorting purpose, you'll get a runtime exception at query time. By
"specifically for sorting" the requirement is that the *single token*
needs to be stored as a DocValue.
DocValues are useful for other purposes too; for example they are a
more efficient strategy to store our "id" field and I hope we'll soon
use that transparently. It's also a better replacement for all those
use cases which previously would rely on a FieldCache (which by the
way was used by the sorting code under the hood). For example, we
recently migrated the Spatial indexing to use DocValues, and we now
support serializing and writing of DocValues.
What we don't have is a way for end user to explicitly single out
which fields they want to be "DocValue encoded", and this really needs
to be added now as the workaround we have to be able to run Sort
operations without it is killing our performance.
How should such annotations look like?
I don't like to expose such low-level details when for most people
it's just about sorting. Still, being useful for other reasons having
a "@Sortable" (or similar) named annotation would be limiting.
DocValues themselves - as a concept - are fine but even in the Lucene
history the exact name changed several times; wondering if we should
stick to the (current) technical term or abstract a bit from it.
I'm not sure if this should be extending the @Field annotation as
there are special restrictions implied in terms of analysis: are we
going to enforce a specific type of tokenizer, or simply take the
analysis option away?
Any nice suggestion of how this could looke like? This would become a
highly used public API.
The good news is that we'll be able to validate sort definitions.
Thanks,
Sanne
8 years, 8 months
InfinispanTestingSetup
by Sanne Grinovero
Context is this IRC question:
<rvansa> [08:14:33] sannegrinovero: Hi, may I ask why have you
sometimes added InfinispanTestingSetup as @ClassRule and sometimes as
@Rule in HHH-10001?
[11:06] <jbossbot> [08:14:34] jira [HHH-10001] Make the testsuite
compatible with Infinispan 8 [Closed (Fixed) Task, Major, Sanne
Grinovero] https://hibernate.atlassian.net/browse/HHH-10001
Hi Radim,
I generally wanted to set it as test rule only as that gives a
stricter cleanup verification, but in some cases the excessive
isolation rules would have it fail: apparently some are relying on
previous tests.
That's something which should be cleaned up in the tests I guess but I
only wanted to workaround the API change in the Infinispan testsuite
without risking a semantic change of the tests.. I also didn't have a
good understanding of the purpose of those tests.
If you're interesting in cleaning that up, you should be able to try
changing the @ClassRule instances to @Rule instances and you'll see
the test fail.
Sanne
8 years, 8 months
Hosting of binaries
by Emmanuel Bernard
As some of you know Sourceforge has had a severe distributed file system corruption and they have been working on it for a full week. You can read their blog for regular updates http://sourceforge.net/blog/
The concrete issue for us is that we cannot upload new files: Hibernate Validator and Hibernate ORM are now pending a release.
There are 4 options on the table
Be patient::
SourceForge will eventually reopen upload, I imagine it might take form one to two weeks.
Their binary hosting support is relatively correct and all of our download statistics are there.
Move to download.jboss.org::
JBoss has a facility to host binaries. WildFly amongst other uses it. We can ask them if they are happy with it.
It is not connected to the rest of the forum/CMS infra, it’s a simple file upload AFAIK so easily scriptable.
They also offer statistics but how needs to be investigated.
Move to GitHub::
GitHub has a binary upload facility. I could only find a web based approach (can it be done programmatically?).
They don’t seem to have any statistics service, which is a big negative point.
Also I don’t trust GitHub anymore for their binary hosting. They had a version in the past that they scrapped with barely no notice. I’m not exactly willing to give them my trust again.
Move to BinTray::
Binary hosting is their life and blood. People seem happy with them. It seems however that the statistics require a paying package instead of the free oss tier.
I think we should try in the following order:
1. Be patient with Sourceforge (but for how long?)
2. go for download.jboss.org and before that ask around for the process and stability of the infrastructure
3. explore Bintray
4. GitHub (did I say that I no longer trust their binary hosting support?)
8 years, 8 months
ORM Documentation
by Steve Ebersole
I have been putting a lot of TLC into the ORM documentation this weekend
getting ready for 5.0 to go Final. To that end I have put together a
proposal for these changes, it is attached. I'd like to get some
feedback. Thanks
8 years, 8 months
4.2.20.Final and SourceForge problems; delaying 4.3.11.Final until next week
by Gail Badner
I am finished with the 4.2.20.Final release, except for uploading distributions due to problems at SourceForge. Artifacts have been successfully uploaded to nexus.
I will wait until Monday to send out an announcement in the hopes that I can upload the distributions to SourceForge by then.
There are a couple more bugfixes I'd like to get into 4.3.11.Final, so I am delaying that release until Wednesday, July 29.
Regards,
Gail
8 years, 8 months
HSEARCH Java 8 Date Time
by Davide D'Alto
Hi,
I started to work on the creation of the bridges for the classes in the
java.time package.
I was wondering if we want to convert the values to long using the existing
approach we have now for java.util.Date.
In Hibernate Search a java.util.Date is converted into a long that
represents the number of milliseconds since January 1, 1970, 00:00:00 GMT
using getTime().
The same value can be obtain from a java.time.LocaDate via:
long epochMilli = date.atStartOfDay( ZoneOffset.UTC
).toInstant().toEpochMilli();
LocalDate has a method that returns the same value expressed in number of
days:
long epochDay = date.toEpochDay();
I would use the second approach
Davide
8 years, 8 months
