Re: [hibernate-dev] HHH-6726 LONG and LONG RAW column types in Oracle
by Łukasz Antoniak
Currently Oracle supports database versions from 10.1 to 11.2 [1]. LONG
and LONG RAW data types are deprecated since version 8 and 8i (released
before September 2000) [2]. Oracle keeps those column types only for
backward compatibility [3].
I tried the following scenario (Oracle 10gR2):
1. Create schema with "hibernate.hbm2ddl.auto" set to "create". The LONG
column is created.
2. Insert some data.
3. Modify Oracle dialect as Gail suggested. Avoid setting
"hibernate.hbm2ddl.auto".
4. Insert some data.
To my surprise the test actually passed :). However, I think that we
cannot guaranty the proper behavior in every situation.
As for performance, ImageType is extracted by calling
ResultSet.getBytes() method, which fetches all data in one call [4]. I
don't suppose a major performance difference when data is streamed in
another call. oracle.jdbc.driver.LongRawAccessor.getBytes also fetches
data by reading the stream.
The bug reading LONG column affects JDBC drivers since version 10.2.0.4.
I think that we have to choose between:
- changing Oracle10gDialect. Make a not about it in migration guide to
4.0 and update "5.2.2. Basic value types" chapter in Hibernate
documentation.
- introducing Oracle11gDialect. It can sound weird to access Oracle 10g
database with Oracle 11g dialect.
- disabling execution of Hibernate tests that fail because of this issue
with @SkipForDialect (and maybe develop another version of them with
CLOBs and BLOBs, @RequiresDialect). Hibernate is written correctly
according to "Default Mappings Between SQL Types and Java Types"
(referenced earlier by Gail) and this is more Oracle's JDBC
implementation issue. This option came to my mind, but it's weird :P.
I would vote for the first option.
Regards,
Lukasz Antoniak
[1]
http://www.oracle.com/us/support/library/lifetime-support-technology-0691...
(page 4)
[2]
http://download.oracle.com/docs/cd/A91202_01/901_doc/server.901/a90120/ch...
[3]
http://download.oracle.com/docs/cd/B28359_01/server.111/b28318/datatype.htm
[4] "Getting a LONG RAW Data Column with getBytes"
http://download.oracle.com/docs/cd/B19306_01/java.102/b14355/jstreams.htm
Strong Liu pisze:
> I think oracle 11g is the only one supported DB version by oracle, can we just introduce a new oracle dialect with suggested changes, and deprecate all other existed oracle dialects? this won't affects users app
>
> -----------
> Strong Liu <stliu(a)hibernate.org>
> http://hibernate.org
> http://github.com/stliu
>
> On Oct 15, 2011, at 11:14 AM, Scott Marlow wrote:
>
>> How does this impact existing applications? Would they have to convert
>> LONGs to CLOBs (and LONGRAWs to BLOBs) to keep the application working?
>>
>> As far as the advantage of CLOB over TEXT, if you read every character,
>> which one is really faster? I would expect TEXT to be a little faster,
>> since the server side will send the characters before they are asked
>> for. By faster, I mean from the application performance point of view. :)
>>
>> Could this be changed in a custom Oracle dialect? So new
>> applications/databases could perhaps use that and existing applications
>> might use LONGs a bit longer via the existing Oracle dialect.
>>
>> On 10/14/2011 09:22 PM, Gail Badner wrote:
>>> In [1], I am seeing the following type mappings:
>>>
>>> Column type: LONG -> java.sql.Types.LONGVARCHAR -> java.lang.String
>>> Column type: LONGRAW -> java.sql.Types.LONGVARBINARY -> byte[]
>>>
>>> org.hibernate.type.TextType is consistent with the mapping for LONG.
>>>
>>> org.hibernate.type.ImageType is consistent with the mapping for LONGRAW.
>>>
>>> From this standpoint, the current settings are appropriate.
>>>
>>> I understand there are restrictions when LONG and LONGRAW are used and I see from your other message that there is Oracle documentation for migrating to CLOB and BLOB.
>>>
>>> I agree that changing column type registration as follows (for Oracle only) should fix this:
>>> registerColumnType( Types.VARBINARY, 2000, "raw($l)" );
>>> registerColumnType( Types.VARBINARY, "blob" );
>>>
>>> registerColumnType( Types.LONGVARCHAR, "clob" );
>>> registerColumnType( Types.LONGVARBINARY, "blob" );
>>>
>>> registerColumnType( Types.VARCHAR, 4000, "varchar2($l char)" );
>>> registerColumnType( Types.VARCHAR, "clob" );
>>>
>>> Steve, what do you think? Is it too late to make this change for 4.0.0?
>>>
>>> [1] Table 11-1 of Oracle® Database JDBC Developer's Guide and Reference, 11g Release 1 (11.1) (http://download.oracle.com/docs/cd/B28359_01/java.111/b31224/datacc.htm#g...)
>>> [2] Hibernate Core Migration Guide for 3.5 (http://community.jboss.org/wiki/HibernateCoreMigrationGuide35)
>>> [3] Table 2-10 of Oracle® Database SQL Language Reference
>>> 11g Release 1 (11.1) (http://download.oracle.com/docs/cd/B28359_01/server.111/b28286/sql_elemen...)
>>>
>>> ----- Original Message -----
>>>> From: "Łukasz Antoniak"<lukasz.antoniak(a)gmail.com>
>>>> To: hibernate-dev(a)lists.jboss.org
>>>> Sent: Thursday, October 13, 2011 12:50:13 PM
>>>> Subject: [hibernate-dev] HHH-6726 LONG and LONG RAW column types in Oracle
>>>>
>>>> Welcome Community!
>>>>
>>>> I have just subscribed to the list and wanted to discuss HHH-6726
>>>> JIRA
>>>> issue.
>>>>
>>>> Gail Badner wrote
>>>> (http://lists.jboss.org/pipermail/hibernate-dev/2011-October/007208.html):
>>>> HHH-6726 (Oracle : map TextType to clob and ImageType to blob)
>>>> https://hibernate.onjira.com/browse/HHH-6726
>>>> There have been a number of issues opened since the change was made
>>>> to
>>>> map TextType (LONGVARCHAR) 'long' and ImageType (LONGVARBINARY) to
>>>> 'long
>>>> raw'. This change was already documented in the migration notes.
>>>> Should
>>>> the mapping for Oracle (only) be changed back to clob and blob?
>>>>
>>>> HHH-6726 is caused by an issue in Oracle JDBC driver (version
>>>> 10.2.0.4
>>>> and later). This bug appears when LONG or LONG RAW columns are
>>>> accessed
>>>> not as first or last while processing SQL statement.
>>>>
>>>> I have discussed the topic of mapping TextType to CLOB and ImageType
>>>> to
>>>> BLOB (only in Oracle dialect) with Strong Liu. Reasons for doing so:
>>>> - Oracle allows only one LONG / LONG RAW column per table. This might
>>>> be
>>>> the most important from Hibernate's perspective.
>>>> - LONG / LONG RAW - up to 2 GB, BLOB / CLOB - up to 4 GB.
>>>> - In PL/SQL using LOBs is more efficient (random access to data).
>>>> LONG
>>>> only sequential.
>>>> - LONG and LONG RAW are deprecated.
>>>>
>>>> What is your opinion?
>>>>
>>>> Regards,
>>>> Lukasz Antoniak
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
8 years, 4 months
Changelog file in Hibernate ORM
by Sanne Grinovero
The file changelog.txt in the root ot the Hibernate ORM project seems outdated.
Is it not maintained anymore? I found it handy.
Sanne
9 years
Re: [hibernate-dev] improved Eclipse project support
by Gunnar Morling
2013/4/16 Steve Ebersole <steven.ebersole(a)gmail.com>
> What is "configured JDK baseline"? Do you have to point to a JDK path? If
> so, no difference than just setting the javac bootstrap option to a local
> path.
No, you don't point to another JDK path, you use the JDK you are on, i.e.
Java 7. You just say which JDK version you want to target, e.g. 1.6. In the
HV case, the config is this:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>animal-sniffer-maven-plugin</artifactId>
<version>1.9</version>
<configuration>
<signature>
<groupId>org.codehaus.mojo.signature</groupId>
<artifactId>java16</artifactId>
<version>1.0</version>
</signature>
</configuration>
</plugin>
The referenced signature artifact contains the API signature for that JDK
version, i.e. all Java 1.6 methods, public fields etc. If your code uses a
method which is not part of that API signature, the plug-in will fail the
build.
That is, you still use the Java 7 API to compile against, but the plug-in
makes sure you use only those parts of the API which where there already as
of Java 6. So this emulates building against Java 6, but without the hassle
of handling several actual JDKs, setting up the boot classpath etc.
>
>
> On Tue 16 Apr 2013 08:38:37 AM CDT, Gunnar Morling wrote:
>
>> In HV, we use the Animal Sniffer plug-in [1] for that purpose.
>>
>> This checks the code base against a configured JDK baseline and fails
>> the build, when e.g. using a method which is not part of the targeted
>> JDK release. In other words, you still use your current JDK for
>> building (avoiding any bootstrap path fiddling) but make sure you
>> invoke only those parts of the API which are also available in the
>> targeted Java version.
>>
>> Together with the source/target level correctly set, this allows to
>> safely compile with newer JDK versions and still be sure that the code
>> e.g. runs on 6.
>>
>> We use the Maven plug-in, but via the Ant task, this should also be
>> usable for Gradle builds. If you like me to, I can give this a try for
>> ORM.
>>
>> --Gunnar
>>
>> [1] http://mojo.codehaus.org/**animal-sniffer/index.html<http://mojo.codehaus.org/animal-sniffer/index.html>
>>
>>
>> 2013/4/16 Steve Ebersole <steven.ebersole(a)gmail.com
>> <mailto:steven.ebersole@gmail.**com <steven.ebersole(a)gmail.com>>>
>>
>>
>> Mainly thats an issue with that fact that so far we have not
>> defined 'bootstrap class path' option to javac to go along with
>> the source/target compatibility settings. The difficulty is that
>> defining bootstrap for javac becomes very system specific (it
>> needs to name a path). Sure we could externalize that into a
>> setting, but then what do you do when someone wants to build
>> Hibernate but has not defined this setting? Do you let the build
>> continue (aka, make the bootstrap setting optional)?
>>
>> Bottom line, just setting source/target compatibility is never enough.
>>
>>
>> On Tue 16 Apr 2013 03:44:29 AM CDT, Gunnar Morling wrote:
>>
>> On a related note:
>>
>> I know Java 7 is required to compile ORM, but is Java 7 also the
>> required runtime Java version now (I vaguely remember a related
>> discussion around the JPA API JAR)?
>>
>> I'm asking, because the Java 7 method
>> Collections#emptyIterator() is
>> used at two places, making this code not runnable on Java 6. If
>> requiring 7 is intentional, feel free to ignore this mail ;)
>>
>> --Gunnar
>>
>>
>>
>> 2013/4/16 Gunnar Morling <gunnar(a)hibernate.org
>> <mailto:gunnar@hibernate.org>
>> <mailto:gunnar@hibernate.org <mailto:gunnar@hibernate.org>>**>
>>
>>
>> 2013/4/15 Steve Ebersole <steven.ebersole(a)gmail.com
>> <mailto:steven.ebersole@gmail.**com <steven.ebersole(a)gmail.com>>
>> <mailto:steven.ebersole@gmail.**__com
>>
>> <mailto:steven.ebersole@gmail.**com <steven.ebersole(a)gmail.com>
>> >>>
>>
>>
>> I am not touching this :)
>>
>> I think I have explained this 198,052 times thus far lol
>>
>>
>> I must have missed this then. Or I was not yet part of the
>> team at
>> that time.
>>
>>
>> https://community.jboss.org/__**__wiki/GradleWhy<https://community.jboss.org/____wiki/GradleWhy>
>> <https://community.jboss.org/_**_wiki/GradleWhy<https://community.jboss.org/__wiki/GradleWhy>
>> >
>>
>>
>> <https://community.jboss.org/_**_wiki/GradleWhy<https://community.jboss.org/__wiki/GradleWhy>
>> <https://community.jboss.org/**wiki/GradleWhy<https://community.jboss.org/wiki/GradleWhy>>>
>> see #4
>>
>>
>> Thanks for the link.
>>
>> I get the reasoning about Maven's "one artifact" rule and
>> the need
>> for re-usable test code. But now that we use Gradle,
>> wouldn't it
>> be possible to move the things from hibernate-testng back to
>> hibernate-core and built two JARs with the different
>> contents from
>> there? To me, a circular dependency between two modules always
>> seems a bit suspicious, also if it is doable with Gradle,
>> turning
>> off warnings in the IDE etc.
>>
>> Btw. also Maven supports this particular use case of
>> creating a
>> main JAR and a JAR with re-usable test infrastructure [1].
>> We e.g.
>> make use of this in HV.
>>
>> --Gunnar
>>
>> [1]
>> http://maven.apache.org/__**plugins/maven-jar-plugin/test-**
>> __jar-mojo.html<http://maven.apache.org/__plugins/maven-jar-plugin/test-__jar-mojo.html>
>>
>> <http://maven.apache.org/**plugins/maven-jar-plugin/test-**
>> jar-mojo.html<http://maven.apache.org/plugins/maven-jar-plugin/test-jar-mojo.html>
>> >
>>
>>
>> On Mon 15 Apr 2013 04:10:43 PM CDT, Gunnar Morling wrote:
>>
>> Hi Brett,
>>
>> That's good news, thanks for your efforts. Based
>> on step 3
>> from your blog
>> post it seems as there still is a circular dependency
>> between some of the
>> modules/projects. Just out of interest, could you give
>> some more details
>> why this kind of setup is required?
>>
>> --Gunnar
>>
>>
>>
>> 2013/4/15 Brett Meyer <brmeyer(a)redhat.com
>> <mailto:brmeyer@redhat.com>
>> <mailto:brmeyer@redhat.com
>>
>> <mailto:brmeyer@redhat.com>>>
>>
>>
>> There's been several complaints about ORM's use of
>> Gradle not generating
>> Eclipse projects correctly. This was recently
>> cleaned
>> up in HHH-7617 [1].
>> FYI, there's a quick blog post [2] about how to
>> quickly get
>> up-and-running. Please let me know if there
>> are any
>> further ways we could
>> streamline the IDE setup.
>>
>> [1]
>> https://hibernate.atlassian.__**__net/browse/HHH-7617
>>
>>
>> <https://hibernate.atlassian._**_net/browse/HHH-7617
>> <https://hibernate.atlassian.**net/browse/HHH-7617<https://hibernate.atlassian.net/browse/HHH-7617>
>> >>
>> [2]
>> http://in.relation.to/____**Bloggers/____**
>> ImprovedEclipseProjectSupportF**____orHibernateORMDevelopment<http://in.relation.to/____Bloggers/____ImprovedEclipseProjectSupportF____...>
>> <http://in.relation.to/__**Bloggers/__**
>> ImprovedEclipseProjectSupportF**__orHibernateORMDevelopment<http://in.relation.to/__Bloggers/__ImprovedEclipseProjectSupportF__orHibe...>
>> >
>>
>>
>>
>> <http://in.relation.to/__**Bloggers/__**
>> ImprovedEclipseProjectSupportF**__orHibernateORMDevelopment<http://in.relation.to/__Bloggers/__ImprovedEclipseProjectSupportF__orHibe...>
>> <http://in.relation.to/**Bloggers/**
>> ImprovedEclipseProjectSupportF**orHibernateORMDevelopment<http://in.relation.to/Bloggers/ImprovedEclipseProjectSupportForHibernateO...>
>> >>
>>
>> Brett Meyer
>> Red Hat Software Engineer, Hibernate
>>
>> ______________________________**_____________________
>>
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> <mailto:hibernate-dev@lists.**jboss.org<hibernate-dev(a)lists.jboss.org>
>> >
>> <mailto:hibernate-dev@lists.__**jboss.org<http://jboss.org>
>> <mailto:hibernate-dev@lists.**jboss.org<hibernate-dev(a)lists.jboss.org>
>> >>
>> https://lists.jboss.org/____**mailman/listinfo/hibernate-dev<https://lists.jboss.org/____mailman/listinfo/hibernate-dev>
>> <https://lists.jboss.org/__**mailman/listinfo/hibernate-dev<https://lists.jboss.org/__mailman/listinfo/hibernate-dev>
>> **>
>>
>> <https://lists.jboss.org/__**mailman/listinfo/hibernate-dev<https://lists.jboss.org/__mailman/listinfo/hibernate-dev>
>> <https://lists.jboss.org/**mailman/listinfo/hibernate-dev<https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>> **>__>
>>
>> ______________________________**_____________________
>>
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> <mailto:hibernate-dev@lists.**jboss.org<hibernate-dev(a)lists.jboss.org>
>> >
>> <mailto:hibernate-dev@lists.__**jboss.org<http://jboss.org>
>> <mailto:hibernate-dev@lists.**jboss.org<hibernate-dev(a)lists.jboss.org>
>> >>
>> https://lists.jboss.org/____**mailman/listinfo/hibernate-dev<https://lists.jboss.org/____mailman/listinfo/hibernate-dev>
>> <https://lists.jboss.org/__**mailman/listinfo/hibernate-dev<https://lists.jboss.org/__mailman/listinfo/hibernate-dev>
>> **>
>>
>> <https://lists.jboss.org/__**mailman/listinfo/hibernate-dev<https://lists.jboss.org/__mailman/listinfo/hibernate-dev>
>> <https://lists.jboss.org/**mailman/listinfo/hibernate-dev<https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>> **>__>
>>
>>
>>
>>
>>
11 years, 1 month
A synchronous JGroups backend for Hibernate Search
by Sanne Grinovero
In my first draft for HSEARCH-1296 I was automatically enabling the
blocking behaviour on JGroups if the worker backend was configured to
be synchronous (which is the default for workers),
but Emmanuel didn't like that and I think he has a good point:
The JGroups behaviour and the workers behaviour are two different
things; so I just separated this into a new configuration property
"block_waiting_ack" (boolean)
which of course applies only to the JGroups backends.
I agree it's important to keep the two separate, but also if the user
is configuring an ASYNC worker, he should set this option to false as
there is no benefit in waiting for the delivery.
Likewise, if SYNC is required, you would probably want to set this to true.
So I'm suggesting we make the default value ot "block_waiting_ack"
dependant on the worker execution, exposing the property as an
override.
Thoughts?
I guess it's much easier to understand the default behaviour if we
keep them separate, still I don't see much use for configuring the two
independently.
Cheers,
Sanne
https://hibernate.atlassian.net/browse/HSEARCH-1296
11 years, 1 month
Hibernate field with custom type changes, but object not marked as 'dirty' for update
by Adnan Raza
Hello hibernate-dev,
Currently I am facing issue with hibernate. I have a Entity class as given
below.
@Entity
@Table(name = TABLE_NAME)
@Access(AccessType.FIELD)
public class EntityClass {
//some fields
//*(a)Access(AccessType.PROPERTY)*
*@Column(name = "WA_DEFINED_TAB_INDEXES")*
* @Type(type = SetToArrayUserType.CLASS_NAME)*
private Set<Integer> oracleArray = new HashSet<>(10);
@Version
@Column(name = "versionCol" , nullable = false)
private Integer rhpVersion = 0;
//some getters/setters
}
In case of AccessType.FIELD mapping, Hibernate doesn't mark object as dirty
and doesn't update row when we only have changes in the fields that is
mapped for custom type. If we have AccessType.PROPERTY mapping, Hibernate
do mark object dirty and make update into database.
is it bug in hibernate?
I there is an open question also
http://stackoverflow.com/questions/1268997/hibernate-field-with-custom-ty...
For the solution, either I will be forced use AccessType.PROPERTY or I have
to mix FIELD and PROPERTY approach.
Please let me know your thoughts about this.
--
*With Best Regards,*
*
** Mohd Adnan*
* Software Developer*
*Mobile +91-7498194516 *
11 years, 1 month
Jenkins Plugins
by Steve Ebersole
Curious what the approach is for applying plugins on ci.hibernate.org.
IIRC Sanne you were wanting to script creation of these servers. Did
that include plugins as well?
I just installed the Gravatar plugin. Was thinking about applying some
others, but then I remember (vaguely) about this scripting. Just wanted
to make sure before I added more.
11 years, 1 month
