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, 11 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, 7 months
Re: [hibernate-dev] Search - HSEARCH-1580 - Dependency graph
by Guillaume Smet
Hi Hardy,
Thanks for your feedback. I'll see what I can do next week about it.
--
Guillaume
On Fri, Jul 25, 2014 at 9:12 PM, Hardy Ferentschik <hardy(a)hibernate.org> wrote:
> Hi,
>
> took a while to respond, but I tend to agree that @ContainedIn would be good enough.
> I don’t think a new annotation would make things clearer. As discussed before, the main
> issue was that the original intention was that @ContainedIn always requires an @IndexedEmbedded.
> It just happened to work also without and during the refactoring the behaviour was changed to
> match the original intentions.
>
> The important thing is to make sure that the documentation and javadocs are documenting the
> behaviour properly and consistently.
>
> So +1 for getting the old behaviour back
>
> —Hardy
>
>
>
>
>
> On 20 Jan 2014, at 11:08, Guillaume Smet <guillaume.smet(a)hibernate.org> wrote:
>
>> Hi,
>>
>> Following the discussion about releasing 5 sooner rather than later, I
>> wanted to point out that we still have to take a decision about
>> HSEARCH-1580:
>> - either commit in 5 the fix we committed to 4.x and update the documentation;
>> - or work on defining another concept.
>>
>> I don't have a strong opinion about what we should do but I have a
>> strong one about doing something before we release 5 :).
>>
>> References:
>> https://hibernate.atlassian.net/browse/HSEARCH-1580
>> https://hibernate.atlassian.net/browse/HSEARCH-1573
>>
>> Feedback welcome.
>>
>> (sorry for the long silence - busy months...)
>>
>> --
>> Guillaume
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
10 years, 1 month
Tests on JDK 9, and other updates on ci.hibernate.org
by Sanne Grinovero
Hi all,
I've installed latest preview builds of:
- JDK 9 b28
- JDK 8u40 b04
Java 9 is new in our builds, so some considerations:
- The JVM option MaxPermSize, which was deprecated in Java8, is no
longer accepted and will fail bootstrap. Either you remove it from
your build path or enable -XX:+IgnoreUnrecognizedVMOptions
- asciidoctor-maven-plugin plugin fails: I'll disable it for now but
it would be great if someone could have a look at it, if it's a JVM
bug we should report it, and otherwise fixing the plugin would be
nice.
On Java 8, a warning:
I've not simply added this beta, but it replaces the current one we
had setup. I realize this is a rather aggressive move, but keep in
mind the current one wasn't a stable release but an early preview as
well.
I guess we might want to split this into a "JDK 8" and a "JDK
8-preview" ? But even our current JDK8 builds are still largely
failing, so I'd rather see some love on that first, then we can move
on into multiple builds.
I would love some help on:
- the animal-sniffer is still broken on Java 8, see what can be done
or let's discuss alternatives
- Some ORM tests are failing on Java8
- Define JDK 9 test builds for more projects:
http://ci.hibernate.org/view/JDK9/
Cheers,
Sanne
10 years, 2 months
[OGM] Removing row keys from associations
by Gunnar Morling
Hi Emmanuel,
Is there any legitimate case where Association#remove(RowKey) is invoked
for a key which is not present in that specific association instance? Or
would this indicate some programming error?
Thanks,
--Gunnar
10 years, 2 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, 2 months
[Search] Internship next year
by Guillaume Smet
Hi,
Just a heads up: I'm going to propose an internship this year (scholar
year more precisely) on Hibernate Search contribution.
I'm not sure I'll find the good intern for this but that's the plan.
The internship season usually starts in Feb/March in France so it's
for early next year.
The internship is located in Lyon, France and if you happen to meet a
good student interested in it, I'll be glad to meet him.
I usually am interested in final year student of French "Grandes
Ecoles" as we name it here but brilliant persons in general are
welcome :).
I have a couple of subjects in mind (like finishing the work I started
on plain text search) but I'm sure we'll be able to find good ideas to
keep a person busy during several months!
--
Guillaume
10 years, 2 months
[ORM] save vs persist for POST_INSERT generators
by Emmanuel Bernard
Hi Steve,
I've got a quick question.
I sort of remember that we were delaying `persist()` operations - until
flush I suppose. This is something we could not do to `save()` because
`persist()` does not force us to return the id while save does. I am in
particular considering the case where the generator is of type
POST_INSERT like a column identifier.
While browsing the code I could not spot any different between the
handing of a save event and a persist event and the actual SQL executoin
seems to happen duing the `persist()` call as opposed to `flush()`.
Is it that I have dreamt it all? Or did we used to do that but not
anymore?
Emmanuel
10 years, 3 months
