Closed GoogleCodeExporter closed 8 years ago
I want to use hibernate (3.6.0<=) + h2 (1.2.144<=) to store lob files. So I
made some research to see if it would actually work.
1. I saw in org.h2.jdbc.JdbcBlob that JDBC 4 methods to modify Blob content are
not supported. For example:
public OutputStream setBinaryStream(long pos) throws SQLException {
throw unsupported("LOB update");
}
I want to note here that some of the new methods are supported (for example the
"free" method both in JdbcBlob and JdbcClob).
2. I also saw that hibernate does some checks to see if the jdbc4 lob methods
can be used or not (if not it falls back to its own lob handling). This is done
in
org.hibernate.engine.jdbc.JdbcSupportLoader.useContextualLobCreation(Connection)
method. So hibernate uses the jdbc provided api if the jdbc
DatabaseMetaData.getJDBCMajorVersion() returns at least 4 and if the free()
method does not throw an exception on a test made Clob object.
3. Add to this I came upon issue #230, this is also listed in the h2 changelog:
"DatabaseMetaData.getJDBCMajorVersion now returns 4 (instead of 3) when the
driver is compiled with Java 6 (the default)."
Based on 1 + 2 + 3 I concluded that I will fail. Because if everything works as
seen in the source code and read in the changelog h2 will pass hibernates lob
support test but will not actually support it.
But I made a maven quick test and it worked! Debugging showed that h2 returns
jdbc support 3 so it seems that point #3 is actually not true. Running
javap -classpath h2-1.2.144.jar -verbose org.h2.jdbc.JdbcConnection | grep major
returned
major version: 49
So it seems the h2 jar in the central maven repo is compiled with java 1.5 and
not 1.6.
The reason I wrote this long story in this issue because I want to highlight
that if that #230 gets fixed for real, lob with hibernate will probably not
work anymore.
Or maybe I just missed something and should be happy that things are working
for now.
Original comment by kiralyat...@gmail.com
on 2 Nov 2010 at 11:11
Thanks! It's definitely a feature that should be added soon.
Original comment by thomas.t...@gmail.com
on 2 Nov 2010 at 7:36
Will be implemented in the next release.
Original comment by thomas.t...@gmail.com
on 5 Nov 2010 at 9:16
Supported in version 1.3.146 (Beta). However, the default h2.jar file is
currently compiled using Java 5, so Hibernate will not use the new feature
using the default jar file.
Original comment by thomas.t...@gmail.com
on 8 Nov 2010 at 9:55
Original comment by thomas.t...@gmail.com
on 14 Dec 2010 at 8:30
The status here shows "Started" but you had said it is in 1.3.146. I see the
latest release as 1.3.153. So is this implemented?
On related note, you had mentioned that "the default h2.jar file is currently
compiled using Java 5". Have you either reconsidered this, or considered
deploying a version built with Java 6 (JDBC 4 support) and uploading to
maven-repo-of-choice as well? You could leverage Maven's notion of a qualifier
for the Java 6 build
Original comment by steven.e...@gmail.com
on 23 Mar 2011 at 8:46
It is supported since version 1.3.146. However, the default h2.jar file is
currently compiled using Java 5, so Hibernate will not use the new feature
using the default jar file.
> Java 5 ... Have you either reconsidered this
Sure. Just I didn't switch to Java 6 yet. I guess this will be done for H2
version 1.4 (maybe earlier).
> You could leverage Maven's notion of a qualifier for the Java 6 build
The H2 build doesn't use Maven, and there are no plans to use Maven. To
understand why, please read the H2 build - you will see it wouldn't fit very
well in what Maven provides, plus there would be many disadvantages when using
Maven. Or did I misunderstand your request?
Original comment by thomas.t...@gmail.com
on 27 Mar 2011 at 6:11
No, I did not mean building with Maven. I meant in terms of making the
artifacts available in the Maven repository. Essentially you can upload 2 jars
for the same release that are distinguished by what is called a classifier. In
your case you could have the default artifact (no classifier) for jdk5 and then
a classified one for jdk6.
Again, you do not have build with Maven.
But it does assume that you are the one that does the uploading to Maven
repository. If you are not, then I would need to direct the request elsewhere.
Original comment by steven.e...@gmail.com
on 27 Mar 2011 at 6:20
> I meant in terms of making the artifacts available in the Maven repository
Ah, OK, yes that's possible. I upload the the files, so I will have a look at
that. Thanks a lot!
Original comment by thomas.t...@gmail.com
on 27 Mar 2011 at 6:51
Hey Thomas, any word on this? Especially as Java 5 is nearing EOL...
Original comment by steven.e...@gmail.com
on 27 Aug 2012 at 6:03
Hi,
I think it does make sense to use Java 6 now by default. I can't promise this
will be the case in the next release, but I will try.
Regards,
Thomas
Original comment by thomas.t...@gmail.com
on 29 Aug 2012 at 7:54
Well more I am even thinking of the multiple artifact uploads I mentioned
before. I think that is the way to go as Java 6 (JDBC 4) and 7 (JDBC 4.1) have
introduced minor JDBC changes, and that is currently the plan for Java 8 (JDBC
4.2) as well. Everyone having to recompile H2 on their own for these different
JREs is not really fun. Especially when you could do it once and upload
artifacts for each...
Original comment by steven.e...@gmail.com
on 29 Aug 2012 at 8:03
This should be fixed in version 1.3.169, as the jar file is now compiled for
Java 6. By the way, it will probably take a while until the jar file is in the
Maven Central repository.
Original comment by thomas.t...@gmail.com
on 9 Sep 2012 at 12:21
Original comment by thomas.t...@gmail.com
on 9 Sep 2012 at 12:21
Original issue reported on code.google.com by
steven.e...@gmail.com
on 8 Oct 2010 at 12:04