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
[Search] Why is global @AnalyzerDefs scanning limited to @Entity?
by Guillaume Smet
Hi,
We would like to declare our global @AnalyzerDefs on a class which
isn't a specific entity.
For the @TypeDefs of Hibernate, we do it by declaring the @TypeDefs on
a class annotated with @MappedSuperClass but with @AnalyzerDefs, we
are forced to declare them on a concrete @Entity.
Is this an oversight or something due to the way the initialization of
Hibernate Search is done and we cannot change?
I know it's only cosmetic but it's a bit ugly to have a dummy entity
and a dummy table in our core framework just to be able to declare
global @AnalyzerDefs.
Thanks for your feedback.
--
Guillaume
11 years, 4 months
[OGM] Embedded MongoDB for tests
by Gunnar Morling
Hi all,
I just came across across "EmbedMongo" [1] which provides a way to run
MongoDB embedded within an application. This is e.g. convenient for tests
as it doesn't require a separately installed MongoDB instance.
I've tried it out with a single test and it worked as expected.
Unfortunately MongoDB (the server) can't be retrieved as Maven dependency,
EmbedMongo thus retrieves the distribution via HTTP and stores it in
~/.embedmongo/. This only happens once during the first usage.
What do you think, would that be helpful to be used for the OGM MongoDB
tests (it might well be that this or similar options have been discussed
before and I just missed that)?
--Gunnar
[1] https://github.com/flapdoodle-oss/embedmongo.flapdoodle.de
11 years, 5 months
Re: [hibernate-dev] hibernate-delta
by Steve Ebersole
That's not true. Neither liquibase nor flyway use a connection to the
database.
On Jun 28, 2013 11:22 AM, "Gregor Zeitlinger" <gr.zeitlinger(a)txtr.com>
wrote:
> The tool you mention works against a database connection which is not what
> I want.
>
> Steve Ebersole <steven.ebersole(a)gmail.com> wrote:
>
> >Tools do exist that do this already. Liquibase and Flyway are 2 I know
> >of. Liquibase even has some support for generating its "change logs"
> >from Hibernate mappings[1].
> >
> >[1] http://www.liquibase.org/documentation/hibernate.html
> >
> >
> >On Mon 24 Jun 2013 07:20:15 AM CDT, Gregor Zeitlinger wrote:
> >> The main difference is that hibernate-delta does NOT run against a live
> >> database.
> >> I do load the previous version of a mapping from a custom XML file.
> >>
> >> This enables some scenarios that are not possible with the hibernate
> >> build in schemaupdate, such as
> >>
> >> 1. add a non-null column
> >> 2. change the datatype of a column
> >> 3. rename a column
> >>
> >>
> >> So the workflow is as follows:
> >>
> >> 1. Create an entity Customer
> >> 2. Run UpdateSqlGenerator (which updates the schema.xml file)
> >> 3. Copy the output to a liquibase or Flyway
> >> 4. commit and push schema.xml
> >>
> >> Note that you do not need any database connection for the entire
> workflow.
> >>
> >> I do like to test it on a scratch dump from the live database when I add
> >> a non-null column and fill it with a qeury for example.
> >> In addition, we have an automated test that executes changesets and
> >> compares the final schema with expected one from the annotations - using
> >> hibernate-delta - which in return uses liquibase to read the schema of
> >> the updated database.
> >>
> >> Gregor
> >>
> >>
> >> Am 24.06.2013 11:24, schrieb Max Rydahl Andersen:
> >>> Looks interesting - what is the big difference between this and
> >>> what the built in schemaupdate does ?
> >>>
> >>> If you don't look at previous versions of the mapping I would not
> >>> expect you to do much better (but if you do that would be the natural
> >>> place to contribute it to)
> >>>
> >>> Do you got an example on how to use this ?
> >>>
> >>> /max
> >>>
> >>> On Thu, Jun 20, 2013 at 11:59:51AM +0200, Gregor Zeitlinger wrote:
> >>>> Hi,
> >>>>
> >>>> I've created https://github.com/txtr/hibernate-delta because I
> couldn't
> >>>> find a solution that would generate SQL update statements based on the
> >>>> fields that I added to my @Entity.
> >>>> The trick is that it stores the schema in an XML file that is commited
> >>>> to git. That way, you only get the differences you introduced.
> >>>> It can also find the differences between your XML schema and the
> actual
> >>>> database (using liquibase).
> >>>>
> >>>> Now the questions
> >>>>
> >>>> 1. Is this something that already exists?
> >>>> 2. Is somebody interested in growing this from the current setup
> >>>> (tested with Oracle only)?
> >>>> 3. Would this maybe even a candidate to include in hibernate tools?
> >>>>
> >>>> --
> >>>> Gregor Zeitlinger
> >>>> gregor.zeitlinger(a)txtr.com
> >>>> _______________________________________________
> >>>> hibernate-dev mailing list
> >>>> hibernate-dev(a)lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
>
11 years, 5 months
Re: [hibernate-dev] hibernate-delta
by Gregor Zeitlinger
The main difference is that hibernate-delta does NOT run against a live
database.
I do load the previous version of a mapping from a custom XML file.
This enables some scenarios that are not possible with the hibernate
build in schemaupdate, such as
1. add a non-null column
2. change the datatype of a column
3. rename a column
So the workflow is as follows:
1. Create an entity Customer
2. Run UpdateSqlGenerator (which updates the schema.xml file)
3. Copy the output to a liquibase or Flyway
4. commit and push schema.xml
Note that you do not need any database connection for the entire workflow.
I do like to test it on a scratch dump from the live database when I add
a non-null column and fill it with a qeury for example.
In addition, we have an automated test that executes changesets and
compares the final schema with expected one from the annotations - using
hibernate-delta - which in return uses liquibase to read the schema of
the updated database.
Gregor
Am 24.06.2013 11:24, schrieb Max Rydahl Andersen:
> Looks interesting - what is the big difference between this and
> what the built in schemaupdate does ?
>
> If you don't look at previous versions of the mapping I would not
> expect you to do much better (but if you do that would be the natural
> place to contribute it to)
>
> Do you got an example on how to use this ?
>
> /max
>
> On Thu, Jun 20, 2013 at 11:59:51AM +0200, Gregor Zeitlinger wrote:
>> Hi,
>>
>> I've created https://github.com/txtr/hibernate-delta because I couldn't
>> find a solution that would generate SQL update statements based on the
>> fields that I added to my @Entity.
>> The trick is that it stores the schema in an XML file that is commited
>> to git. That way, you only get the differences you introduced.
>> It can also find the differences between your XML schema and the actual
>> database (using liquibase).
>>
>> Now the questions
>>
>> 1. Is this something that already exists?
>> 2. Is somebody interested in growing this from the current setup
>> (tested with Oracle only)?
>> 3. Would this maybe even a candidate to include in hibernate tools?
>>
>> --
>> Gregor Zeitlinger
>> gregor.zeitlinger(a)txtr.com
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
Gregor Zeitlinger
gregor.zeitlinger(a)txtr.com
Notice
The information in this message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying or distribution of the message, or any action taken by you in reliance on it, is prohibited and may be unlawful. If you have received this message in error, please delete it and contact the sender immediately. Thank you.
11 years, 6 months
