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, 10 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, 5 months
Re: [hibernate-dev] Closed pull requests
by Steve Ebersole
Well telling me/us which PRs got closed would be a good first step :)
Overall, checking that the PR still applies is a good idea too.
On Thu, Oct 30, 2014 at 5:34 PM, Andrej Golovnin <golovnin(a)gmx.net> wrote:
>
> > On 30.10.2014, at 23:15, Steve Ebersole <steve(a)hibernate.org> wrote:
> >
> > Well maybe rather than being hurt and sensitive maybe just understand
> that it was not intentional. GitHub automatically closed them. It was
> simply a mistake.
> >
> > Or be sensitive and threatening about it. Whichever you think helps you
> best ;)
>
> This does not answer my 1. question. :-) What is the best way to proceed?
> Are you going to reopen the pull requests or should we create new requests?
>
> I think, that at least one of my patches must be modified to be applied to
> the "new master".
>
> Any clear small guide, what we (contributors) should do to reopen the pull
> requests
> or a small info that you will care about the closed pull requests
> and we should sit down, relax and wait until you are done, would be really
> helpful.
>
> >
> > On Oct 30, 2014 11:05 PM, "Andrej Golovnin" <golovnin(a)gmx.net> wrote:
> > Hello Steve,
> >
> > you have closed my pull requests and
> > pull requests from others too without any comment.
> >
> > Should we create a new pull requests for the "new master" branch?
> > Or should we just forget all the time and the work we have invested
> > to create those pull requests and stop submitting any new pull requests
> > in the future?
> >
> > Best regards,
> > Andrej Golovnin
>
>
9 years, 11 months
ORM master
by Steve Ebersole
Per the face to face discussion yesterday (I'll send out more details
later) I am working on branching master off to a new "metamodel" dev branch
and priming a "new master" from 4.3 (the basic idea being to start work on
a more targeted 5.0).
Part of this is of course a massive change to the state of master upstream.
If anyone needs me to wait before starting this please let me know
immediately. Thanks.
10 years
Hibernate ORM master - 5.0
by Steve Ebersole
It was decided that the massive work for 5.0 including metamodel and all
the other changes was just taking too long, and that we'd split that work
up into a number of intermediate versions. I wanted to highlight the
proposed breakdown and solidify the roadmaps. The preliminary breakdown is
as follows:
- 5.0
- Java 6 or 7 (?)
- EE 7 (JPA 2.1)
- Wildfly 9
- Timeline : Spring 2015
- Required development
- Transition to new bootstrapping APIs
- MetadataSources, contributors, builders, etc for building
SessionFactory
- Keep Configuration as a migration aid, but align its
processing and assumptions to follow new APIs
- New naming strategy approach (implicit and physical split)
- Pick "important" features from metamodel work based on new
bootstrapping API
- automatic quoting of identifiers that are keywords
- ???
- Performance improvements
- Cachng SPI changes based on feedback from Ehcahce and Infinispan
- EntityKey proposal
- Explore unifying entry keys for actual cache provider, cache
SPI (CacheKey) and persistence-context (EntityKey)
- Infinispan improvements, especially in local mode. Will
require integrating a new Infinispan version and possible
changes to
hibernate-infinispan
- ???
- OGM integration
- "after persisters built" hook
- others?
- Java 8 type support
- Date/Time
- Optional
- Java 9 type support
- Money/Currency
- Optional development (as time, resources allow)
- Discriminator based multitenancy
- JAXB instead of dom4j.
- extended orm.xml xsd, deprecating hbm.xml format
- Jandex usage
- JdbcSession
- Hibernate Spatial integration (depends on level of dependence on
metamodel)
- 5.1
- Java 6 or 7 (?)
- EE 7 (JPA 2.1)
- Widfly 9, or 10
- Timeline : TBD (Fall 2016?)
- Required development
- slips from 5.0
- new HQL parser
- Antlr 3 or 4?
- unified SQL generation? or limit to HQL parsing?
- Optional development (as time, resources allow)
- extend JPA criteria API with support for constructs from
Hibernate's legacy criteria API
- extend JPA criteria API with fluent support
- Possibly - Override EAGER fetching with LAZY (fetch profiles, HQL,
etc)
- 5.2
- (if needed)
- Java 6 or 7 (?)
- EE 7 (JPA 2.1)
- Widfly 9, or 10
- Required development
- splits from 5.1
- 6.0
- SE and EE support levels TBD, but at least SE 8
- Required development
- metamodel
One additional consideration... I have been told (have not verified the
details yet myself) that Hibernate ORM will currently not run in Java 8 at
least in part because dom4j will not work in Java 8 (maybe just the version
we use? again, have not verified details yet). If running 5.x versions of
Hibernate in Java 8 is important to anyone, we might need to increase the
priority of moving to JAXB over dom4j.
10 years
Re: [hibernate-dev] hibernate-dev Digest, Vol 100, Issue 8
by Marc Schipperheyn
I'm disappointed to see Spring 2015 on HSEARCH 5.0. Especially given how
long Lucene 4 has been in the field (October 2012). HSEARCH seemed to be at
a standstill for most of this year.
I would prefer to cut down on features to see it sooner, but I guess that's
not an option anymore. Also, I would say the risk is Lucene will run out of
4.x-es and move on to 5.x
Cheers,
Marc
10 years
Antlr 4 PoC
by Steve Ebersole
I started working on a proof-of-concept for using Antlr 4 for query parsing
in Hibernate. It is very rudimentary at this point. It is pushed to
GitHub here: https://github.com/sebersole/hibernate-antlr4-poc
This is mean as an attempt to determine whether/how Antlr 4 could/would
work for our needs. Because Antlr 4 was such a big deviation from versions
2 and 3 we need to see how we can map many of the paradigms and patterns we
use in our existing parsers.
10 years
Hibernate ORM 4.3.7.Final and 4.2.16.Final Released
by Gail Badner
I've finished with the releases, including uploading everthing. I'm having trouble setting up the weblog entry in in.relation.to for some reason. I'll blog about the releases tomorrow.
Regards,
Gail
10 years
Closed pull requests
by Andrej Golovnin
Hello Steve,
you have closed my pull requests and
pull requests from others too without any comment.
Should we create a new pull requests for the "new master" branch?
Or should we just forget all the time and the work we have invested
to create those pull requests and stop submitting any new pull requests
in the future?
Best regards,
Andrej Golovnin
10 years
