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
Re: [hibernate-dev] Where are the batched fetch statements generated?
by Clemens Eisserer
Hi Guenther,
>>> Is it possible to disable prepared statement caching for batched fetching, so I end up with a single query in the < default_batch_fetch_size case only >>instead of the
>>> fixed-size batch loading hibernate does by default?
> I think the main reason for no feedback so far, is that nobody was able to understand this sentence.
> Usually 'prepared statement caching' is a synonym to 'prepared statement pooling' and is something which has to be provided by a connection-pool (or a jdbc-driver) and thus
> Hibernate does actually not implement any prepared statement cache/pooling.
> Can you please explain what you intend under 'prepared statement caching'?
> Can you also please try to better explain the second part of your sentence?
Sorry for beeing that cryptic, I will try to rephrase it:
When Hibernate does batch-fetching, it generates PreparedStatements
for certain batch sizes - for a batch_size of 50, the prepared
statements for batch-sizes will have the following sizes:
[1,2,3,4,5,6,7,8,9,10,12,25,50]. When e.g. a batch of size 13 should
be fetched, because of the fixed size of the prepared statements, 3
queries are issued for batch-fetching, although 13 <= 50. In this case
the 3 batches would be of the size 13 = 8 + 4 + 1.
In a latency bound (between db and application) environment, this
serverly hampers response time - instead of a single round-trip to do
the batched fetch, Hibernate requires 3.
(subselect can't be used in my case, because my queries are already
rather complex, and the added complexity confuses the DBs query
planner too much)
What I did in this case (only for integer PKs) is to pad up to the
next batch size with a non-existant PK.
So, for the example mentioned above, I can use the PreparedStatement
with size 25, and insert padding from 14-25, which will make the query
slightly more inefficient but avoid 2 additioan round-trips.
- Clemens
12 years, 1 month
Fwd: Re: Proxies and typing
by Steve Ebersole
Forwarding a part of this discussion that got inadvertently limited to
just Sanne and myself.
Bringing this back up because this is most likely not going to be
accepted into JPA 2.1. Anyway, I am all for going down the path that:
public interface User {
...
}
@Entity
@Proxy(proxyClass=User.class)
public class UserImpl implements User {
...
}
means that users would use User.class in all phases of the API:
User user = session.byId( User.class ).get( 1 );
EntityType<User> jpaEntityType = emf.getMetamodel().entity(User.class );
etc.
I think that is the cleanest path that allows generic-typed api.
-------- Original Message --------
Subject: Re: [hibernate-dev] Proxies and typing
Date: Thu, 26 Jan 2012 14:37:22 +0000
From: Sanne Grinovero <sanne(a)hibernate.org>
To: Steve Ebersole <steve(a)hibernate.org>
On 26 January 2012 14:02, Steve Ebersole <steve(a)hibernate.org> wrote:
> These emails are just between you and me. Not sure if thats what you
> intended. I erroneously replied to just you at one point but then sent to
> whole list also. Anyway, just mentioning...
Ah, sorry, didn't notice either. Well last reply then, will try resume
the public conversation if I have more comments.
> The idea of requiring the interface is appealing in a way. But, for
> example, there are odd inconsistencies then. For example
>
> User user = session.byId( User.class ).get( 1 );
>
> but then
>
> EntityType<UserImpl> jpaEntityType = emf.getMetamodel().entity(
> UserImpl.class )
>
>
> Which I guess is my biggest hang up. On one side we are saying that the
> impl is the entity and on the other saying the interface is the entity.
>
> You know me and consistency :)
I agree on consistency, but this is tricky, I'm not sure if you need
the UserImpl at all, maybe you can remove it from the MetaModel (maybe
after having read out other metadata from it).
Isn't such a mapping definition like a dirty workaround to actually
map the interface ?
Sanne
12 years, 5 months
Typing Help with JPA 2.1 impl
by Steve Ebersole
I need some help with generic types in the JPA 2.1 API, specifically
with regard to the new Join#on and Fetch#on methods. We ultimately
unify those 2 interface hierarchies into a single hierarchy in out code
using org.hibernate.ejb.criteria.JoinImplementor which extends from both
Join and Fetch.
The problem I am facing is in the return types. So, Join defines:
public interface Join<Z,X> {
public Join<Z,X> on(...);
...
}
Fetch defines:
public interface Fetch<Z,X> {
public Fetch<Z,X> on(...);
...
}
public interface JoinImplementor<Z,X>
extends Join<Z,X>, Fetch<Z,X>, FromImplementor<Z,X> {
...
}
The compiler does not at all like JoinImplementor as is, so I have to
override the method:
public interface JoinImplementor<Z,X>
extends Join<Z,X>, Fetch<Z,X>, FromImplementor<Z,X> {
public JoinImplementor<Z,X> on(...);
...
}
which should be fine as it is simple return type clarification. And
actually that definition compiles fine.
However, JPA also defines a whole hierarchy from Join such as.
CollectionJoin, ListJoin, etc. So Hibernate has for example:
public interface CollectionJoinImplementor<Z,X> extends
JoinImplementor<Z,X>, CollectionJoin<Z,X> {
@Override
public CollectionJoinImplementor<Z, X> on(...);
...
}
The IDE is fine with this type signature, however trying to compile this
leads to the following error:
types org.hibernate.ejb.criteria.JoinImplementor<Z,X> and
org.hibernate.ejb.criteria.JoinImplementor<Z,X> are incompatible; both
define on(javax.persistence.criteria.Predicate[]), but with unrelated
return types
I have no idea what I need to do here. Can anyone see the solution?
--
steve(a)hibernate.org
http://hibernate.org
12 years, 5 months
JPA 2.1 progress
by Steve Ebersole
Just wanted to let everyone know that implementing JPA 2.1 support is
moving along. I had too much work here that I was worried about losing
so I went ahead and pushed it to my fork.
Draft 6 from the expert group is almost completely implemented at this
point. The only outstanding item left from Draft 6 is support for
"AttributeConverters" which I'll start on next.
If anyone wanted to start playing around with it or looking at it, like
I said, its pushed to my fork:
https://github.com/sebersole/hibernate-core/tree/jpa21
I went a slightly different approach with our shiny new native stored
procedure support compared to the JPA approach. The hope was to make it
easier to deal with the potential multiple interleaved
ResultSet/updateCount returns. Let me know if anyone has design
improvements there.
Subquery support on CriteriaUpdate and CriteriaDelete objects is still
undefined waiting for an updated spec addressing a problem there.
Other than that (and the AttributeConverter stuff) I fully expect this
to fully address Draft 6.
--
steve(a)hibernate.org
http://hibernate.org
12 years, 5 months
Pull request for HHH-2394 (Support filter tag in subclass)
by Rob Worsnop
https://github.com/hibernate/hibernate-orm/pull/339
It seemed that the challenge to overcome was that Hibernate did not
know which aliases to use when generating the where clauses for
filters. When filters are not allowed on subclasses (current
situation), the alias for the root entity is used for all where
clauses. So when FilterHelper is asked to render the filters, it does
so with a single alias string.
So my changes revolve around two themes:
1. Remembering the filter's associated table so that we can generate
an appropriate alias. This was done by replacing the name->condition
map with a list of FilterConfiguration objects. This is a new class
and includes a qualified table name (as well as the name and
condition, of course).
2. Passing a callback (instead of the alias string) to
FilterHelper.render() that allows it to generate an appropriate alias
for each filter, depending on table name. The callback is an
implementation of a new interface, FilterAliasGenerator. The
implementation varies by context.
Where filters are applied to entities, we know the table name. When
filters are applied to collections we do not. My solution to this is
potentially controversial and I'd be interested in hearing
alternatives to it. I have expanded the @Filter annotation to include
a table name. This is an optional element because it makes no sense
when @Filter is applied directly to an entity. That's what I don't
like about this idea.
For example:
@OneToMany(mappedBy="club")
@Filters({
@Filter(name="iqMin", table="ZOOLOGY_HUMAN", condition="HUMAN_IQ >= :min"),
@Filter(name="pregnantMembers", table="ZOOLOGY_MAMMAL",
condition="IS_PREGNANT=1")
})
private Set<Human> members = new HashSet<Human>();
This is excerpted from here:
https://github.com/rworsnop/hibernate-orm/blob/HHH-2394/hibernate-core/sr...
Thoughts?
12 years, 5 months
Re: [hibernate-dev] Jira / GitHub
by Steve Ebersole
I will work on getting the rest moved today. I really wanted to get
tools moved to this as it talks to the JBoss FishEye and can really
slow down all access to the JIra server as a whole.
I will also be removing the FishEye repo links.
On Fri 29 Jun 2012 08:04:10 AM CDT, Steve Ebersole wrote:
> I will work on getting the rest moved today. I really wanted to get
> tools moved to this as it talks to the JBoss FishEye and can really
> slow down all access to the JIra server as a whole.
>
> I will also be removing the FishEye repo links.
>
> On Fri 29 Jun 2012 06:05:00 AM CDT, Sanne Grinovero wrote:
>> +1 ! Thanks Steve!
>>
>> On 29 June 2012 10:34, Nicolas Helleringer
>> <nicolas.helleringer(a)gmail.com> wrote:
>>> Very nice indeed
>>>
>>> Niko
>>>
>>> 2012/6/29 Hardy Ferentschik <hardy(a)hibernate.org>
>>>
>>>> +1 Looks very nice. I think we should enable it for the other
>>>> projects as
>>>> well.
>>>>
>>>>
>>>> On Jun 29, 2012, at 4:48 AM, Strong Liu wrote:
>>>>
>>>>> seems open the change set in github is faster than fisheye, and more
>>>> cleaner on github
>>>>>
>>>>> nice!
>>>>>
>>>>> On Jun 29, 2012, at 2:42 AM, Steve Ebersole wrote:
>>>>>
>>>>>> Finally got GitHub integration set up in Jira. Talking about the
>>>>>> direct, built-in Jira support for GitHub, not talking to GitHub
>>>>>> through
>>>>>> FishEye.
>>>>>>
>>>>>> So far I have only enabled it on the ORM project (HHH). Take a
>>>>>> look-see
>>>>>> and let me know what you think.
>>>>>>
>>>>>> In HHH issues, you will see there are now 2 tabs: Source (the
>>>>>> FishEye
>>>>>> tab) and Commits (the GitHub connector tab). For example,
>>>>>> https://hibernate.onjira.com/browse/HHH-7084
>>>>>>
>>>>>> Both show up in activity streams.
>>>>>>
>>>>>>
>>>>>> --
>>>>>> steve(a)hibernate.org
>>>>>> http://hibernate.org
>>>>>>
>>>>>> _______________________________________________
>>>>>> hibernate-dev mailing list
>>>>>> hibernate-dev(a)lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>
>>>>> -------------------------
>>>>> Best Regards,
>>>>>
>>>>> Strong Liu <stliu at hibernate.org>
>>>>> http://about.me/stliu/bio
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
steve(a)hibernate.org
http://hibernate.org
12 years, 6 months
Jira / GitHub
by Steve Ebersole
Finally got GitHub integration set up in Jira. Talking about the
direct, built-in Jira support for GitHub, not talking to GitHub through
FishEye.
So far I have only enabled it on the ORM project (HHH). Take a look-see
and let me know what you think.
In HHH issues, you will see there are now 2 tabs: Source (the FishEye
tab) and Commits (the GitHub connector tab). For example,
https://hibernate.onjira.com/browse/HHH-7084
Both show up in activity streams.
--
steve(a)hibernate.org
http://hibernate.org
12 years, 6 months
Re: [hibernate-dev] Hibernate.next version and AS 7.2 community release...
by Sanne Grinovero
There are a lot of libraries depending on Hibernate Commons
Annotations, up to Infinispan for the Query module (not depending on
any other Hibernate core library).
If you want to rewrite it's internals and provide a drop-in
replacement, that's nice. But I see no reason to throw it away?
Could you please list why it should be rewritten from scratch? Not
just for me only, I also think it's nice to clarify the goals of a
rewrite.
I admit I am not familiar with it's internals.. but that's IMHO a very
good sign, in two years working on these projects I only had to open a
single JIRA on it [1], and it wasn't a bug nor urgent... that's damn
cool.
Finally, the wide set of dependent projects remind me of JBoss Logger;
Logger is well written and quite solid, still even the small problems
we found with it proved disruptive because of the need to align the
version across so many components.. and I don expect anyone to rewrite
such a tricky library correct at first shot, considering H.C.A.
contains the code to infer the type out of generics.
There were good reasons to move to JBoss Logger; do we have super good
reasons to rewrite this?
I'm for incremental and backwards compatible changes.
On 26 June 2012 19:39, Steve Ebersole <steven.ebersole(a)gmail.com> wrote:
> Agree 10,000%
Cool, in European notation that's not much :-)
Sanne
1 - The classloader API improvements for Search in CapeDwarf
12 years, 6 months
Hibernate.next version and AS 7.2 community release...
by Scott Marlow
I'm going to look at improving the AS7 boot time for JPA applications as
part of the AS 7.2 release (perhaps for the first 7.2 alpha if
possible). I'll collect more details about the improvements that I want
to make (with regard to were we are spending excessive time for
deployments that need improving as I learn more about them from Jason).
As part of this effort for the AS 7.2 release, I may come up with
Hibernate improvements/issues (in
persistenceProvider.createContainerEntityManagerFactory()) that would be
good to include changes for. I think that now is a good time for a
discussion of what Hiberate ORM version should be included in AS 7.2. I
hope that it is a release higher than 4.1.4 (so that we can make further
Hibernate ORM improvements).
I think another requirement for the Hibernate release that we integrate
into AS 7.2, is that it be compatible with the project stack expected to
work with AS 7.2 (Seam 2.3, Spring, Infinispan 2lc integration, other
Hibernate portfolio projects, customer applications). This will be
important when the AS 7.2 changes are merged into a product branch.
Scott
12 years, 6 months