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
>
9 years, 2 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, 11 months
Signing up for JIRA
by Gunnar Morling
Hi,
In JIRA I'm seeing this permanent message:
"Need to file a bug report and don't have an account? Email emmanuel at
hibernate dot org with JIRA Account creation as subject. You'll receive an
invite by email."
So have we abandoned the self sign-up? Why is this, due to spamming issues?
Not sure whether it's really a problem, but this may raise the barrier for
getting a JIRA account and thus stop some new users from reporting bugs.
--Gunnar
10 years, 6 months
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 :)
10 years, 8 months
Gradle, ORM and Mac OS X
by Emmanuel Bernard
I had a lot of hurdles to make Hibernate ORM run and build on Mac OS X and IntelliJ IDEA so here are a few tidbits:
I give Gradle 1GB
export GRADLE_OPTS="-Xmx1024M"
Gradle hangs on me after ~ 2300 to 2400 tests for hibernate-core subsystem. Basically at least one of the worker hangs for ever.
To work around that I forced Gradle to use one thread
./gradlew -no-daemon --parallel-threads 1 clean test
IntelliJ IDEA does not import ORM properly on Mac OS X. I tried both to run IDEA with Java 6 (default) and Java 7 (hacked). The way around that is to use `./gradlew idea` and open the project in the IDE. You then have to manually add the generated source directory in a few modules.
Things are explained here: https://community.jboss.org/wiki/ContributingToHibernateUsingIntelliJ
Emmanuel
10 years, 9 months
Configuration and custom IdentifierGeneratorFactory implementations
by Gunnar Morling
Steve, all,
I would like to work with a custom IdentifierGeneratorFactory which
performs a specific configuration of created generators (basically I want
to pass OGM's GridDialect instead of the original Dialect contract).
Now the problem is that DefaultIdentifierGeneratorFactory is hard-wired in
Configuration, from where it is accessed in the SessionFactoryImpl
constructor. In my particular case the instantiation of Configuration is
not under my control, so I can't sneak in a custom factory via a sub-class.
Interestingly, (Mutable)IdentifierGeneratorFactory is also a service
contract and as such is accessed via the service registry in other places.
My understanding is that Configuration is supposed to go away in ORM 5
anyways, so I'm wondering whether there is a low-effort solution to my
problem as of 4.3.x.
Would it be feasible to add Configuration#setIdentifierGeneratorFactory()
for that purpose? This should help my case; It would require though that
Configuration#mapping is calculated lazily since atm. it captures a
reference to the initially set generator factory.
Any thoughts?
Thanks,
--Gunnar
10 years, 10 months
[OGM] Id generation strategies
by Gunnar Morling
Hi,
I'm rather confused by the way how OgmIdentityGenerator,
OgmSequenceGenerator and OgmTableGenerator interact.
Basically, the first two just delegate to the latter. Now intuitively I'd
have expected an exception when explicitly using a generation type not
supported on a given datastore, say @GeneratedValue(strategy =
GenerationType.SEQUENCE) on MongoDB. But as we always delegate to the table
strategy, such exception is not raised.
Also several attributes of generator annotations are ignored; E.g.
naturally(a)SequenceGenerator.sequenceName(), but also
@TableGenerator.valueColumnName.
What has been the motivation behind this design?
I guess a change to GridDialect may be required for making explicit which
strategies are supported on a given backend.
Thanks,
--Gunnar
10 years, 10 months
Removal of Hibernate Commons Annotations from Hibernate Search -> middle-ground solution?
by Sanne Grinovero
This has been proposed several times, it's time to try converging on a
stable API for Hibernate Search 5, and I have the idea that actual
plans to remove the dependency are not mature.
I would then propose to re-purpose HSEARCH-1213 to not fully remove
hibernate-commons-annotations but to use it as an implementation
detail only: make sure we hide it from user API, so to allow us to
remove it later when possibly Hibernate ORM will be aligned on these
plans too.
Any suggestion on how we could verify this is done correctly?
I thought of using checkstyle to consider it a violation to import
HANN classes in the tests, but that's probably not solid enough - and
some tests might need exceptions to the rule.
Sanne
10 years, 10 months
