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
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
Quoted names
by Dmitry Geraskov
Hi, guys,
I am working on the hibernate tools code generation problem for tables
which has quoted names (name, schema or catalog has special symbols(dot
for ex.)).
Any reason why Table#setName(x) and Table#setSchema(x) have "unquote"
logic, but Table#setCatalog(x) does not?
Dmitry Geraskov
12 years, 6 months
[OGM] Transaction-aware
by Pawel Kozlowski
hi!
First of all, thank you for coming up with the idea & implementing
OGM. For quite some time I was thinking of using JPA annotations /
semantics to drive different NoSQL stores but the whole idea of
re-implementing the JPA machinery was really scary. Now we don't need
to do this anymore as we've got OGM :-)
For the few past days I was looking at the
org.hibernate.ogm.dialect.GridDialect interface (as well as at the
existing Map, Infinispan and Ehcache implementations) and it looks
like it is very easy to implement non-transactional behavior (I mean -
persistence of tuples and associations is really straightforward).
What I was struggling with thought is making a NoSQL store aware of
the JTA-transaction demarcation. What I would like to achieve is to
start a transaction in the underlying store (on transaction begin) and
commit/roll it back inside data store when the JTA transaction is
committed / rolled-back.
Looking at the existing implementations it wasn't easy to figure out
how to achieve this. Moreover I've bumped into this discussion:
http://www.mail-archive.com/hibernate-dev@lists.jboss.org/msg07373.html
where Emmanuel provided his insight: "Form this discussion it also
seems that we might need to have datastores and
dialect implement the Hibernate transaction object so that the datastore can
properly demarcate when isolation starts and when it ends. But that's clearly
not abstracted yet in Hibernate OGM."
In the end my question is rather simple (although answer might be
not...): what would be OGM-way to start / commit a transaction in the
underlying data store in response to JTA transaction events? Or am I
asking totaly wrong question and I should be taking a different
approach? Would be grateful for any insight.
Cheers,
Pawel Kozlowski
12 years, 8 months
multi-tenancy in Hibernate and JPA 2.1
by Steve Ebersole
The scope of multi-tenancy in JPA 2.1 is pretty much set it seems, its
just details at this point. And that scope is decidedly different from
what I did for Hibernate. What we have in Hibernate is actually more
encompassing.
The terms being used to describe the differences are PaaS versus SaaS.
What we have in Hibernate falls into what the spec committee is calling
the SaaS category, essentially the ability to run one instance of the
application (and therefore one instance of Hibernate) simultaneously
handling multiple tenant requests. This is stated to be outside the
scope of multi-tenancy for JPA 2.1. Instead JPA 2.1 will support what
the committee is calling PaaS category, essentially multiple instances
of the application (and therefore multiple instances of Hibernate) would
be needed to handle multiple client requests.
Essentially, you could largely achieve what is planned for multi-tenancy
in JPA 2.1 using JPA 2.0 or earlier. But there will be some caveats to
multi-tenancy in JPA that we will need to deal with, which I wanted to
start discussing.
First I think we should completely not use the existing multi-tenancy
stuff in our support for JPA 2.1 multi-tenancy. Hibernate
multi-tenancy, as it exists already, has some "overheads" thAt simply
are not needed for the JPA use-case. For example, in Hibernate
multi-tenancy (or "Saas multi-tenancy"), there is a need to know which
of multiple available pools to use for getting Connections for use with
particular tenants. But that is simply not needed for JPA multi-tenancy
(or "PaaS multi-tenancy") because that running JPA provider instance can
handle only one tenant at a time. Similar deal with second level cache
keys: no need to encode tenant id into the key. That app will hold only
one tenant's data (unless multiple apps share the same cache instances,
but that's handle-able by prefixing the regions per app/tenant).
If we do end up leveraging the existing multi-tenancy support, we will
additionally need to know the type of multi-tenancy in effect. Here I
mean this question of SaaS versus PaaS rather than the question of
SEPARATE_DATABASE versus SEPARATE_SCHEMA versus DISCRIMINATED.
JPA is proposing some limitations to available features based on the
type of multi-tenancy (if any) is used in the application that we should
go back and look at, even for our SaaS stuff. For example, in the
SEPARATE_SCHEMA the current proposal is to disallow the deployment from
referencing schemas/catalogs at all, which is a good idea. There is
also proposed limitations on native-sql queries such that:
1) they would not be portably available if using DISCRIMINATED, although
persistence providers could choose to support it if they can handle
injecting any needed discriminator fragments
2) could not reference schemas/catalogs in the SEPARATE_SCHEMA, which is
totally inline with the limitation on naming schemas/catalogs in general
in SEPARATE_SCHEMA.
Personally, I find all of the proposed limitations outlined above
reasonable. There is a question of whether we would want to support
native-sql queries in the DISCRIMINATED case. Take an example where the
user supplies a query like [select ... from CUST_TBL c]. Obviously we
need to limit that to return just their data, so we would need to
instead pass a query along to the database like [select ... from
CUST_TBL c where c.tenant = 'acme'] (assuming 'acme' is the current
tenant identifier). It is a lot to bite off to support this
unilaterally, because often folks are resorting to native-sql queries
because they need to leverage some db-specific SQL syntax/feature and
that is essentially impossible to properly parse and interpret. One
option is that we could instead allow a placeholder: [select ... from
CUST_TBL c where c.tenant = ${tenant}]. But even here we still have
difficulty with being able to guarantee that we catch all cases. So in
the end, I am not sure this is something we should be doing.
Anyway, if y'all have thoughts I'd like to hear.
--
steve(a)hibernate.org
http://hibernate.org
12 years, 8 months
Meeting
by Steve Ebersole
I got dropped from my portable internet and cannot connect at all at the
moment. We really need to change this meeting time. The current time is
unworkable for me every other week. Either we need to move this 2.5 hours
later or move it to another day. If another day, Thursday is the only other
day that works for me in the same general timeframe.
steve(a)hibernate.org
http://hibernate.org
12 years, 9 months
patching javassist - which ver?
by Nikita Tovstoles
Hello,
Long time listener, first time caller here - thanks for an excellent
framework.
We've been profiling our Hibernate 3.6.10-based app and noticed a perf
bottleneck in javassist.util.proxy.RuntimeSupport.find2methods.
Unfortunately, this method, which has a synch. block, is being called on
every invocation of every proxied entity method (see
javassist.util.proxy.ProxyFactory.makeForwarder(), called indirectly by
ProxyFactory.createClass()). In our testing, the result is that our service
call's latency increases from 33 to 55, 260, 400ms as concurrency increases
1-10-20-30 users on a 4-core CPU. At 20 and 30 users 51% of CPU time is
spent contending for a monitor in RuntimeSupport.find2methods.
Since find2methods merely interrogates class metadata, seems like its return
values should be cached (in a ConcurrentMap?). Since this is a big problem
for us, I am happy to submit a patch to javassist, but would like to know
which version should I be patching, given that I am primarily interesting in
using javassist in conjunction with Hibernate? Currently, hibernate-core
4.1.1 uses javassist 3.15.0-GA, 3.10.Final uses 3.12. Latest GA is 3.16-1.
I'd appreciate any other advice as well (perhaps this problem's been
discussed?)
Thank you,
-nikita
12 years, 9 months
Unsaved values
by Gail Badner
At the team meeting in Austin, I remember discussion about cases where different "strategies" were needed to process values obtained from annotations and hbm.xml sources. I can't remember if we discussed unsaved values, but it seems to me that this is one case where this is needed.
I created a pull request for dealing with unsaved values: https://github.com/hibernate/hibernate-orm/pull/298.
Please take a look and provide feedback to let me know if I'm on the right track.
Thanks,
Gail
12 years, 9 months
Natural ID caching bug?
by Galder Zamarreño
Hi guys,
I think there's a bug in the Natural ID support impl in Hibernate and wanted to confirm with you:
For entity caching, EntityInsertAction does:
boolean put = persister.getCacheAccessStrategy().insert( ck, cacheEntry, version );
if ( put && factory.getStatistics().isStatisticsEnabled() ) {
factory.getStatisticsImplementor().secondLevelCachePut( getPersister().getCacheAccessStrategy().getRegion().getName() );
}
But for natural id caching, insert() return is ignored and only afterInsert()'s result is taken into accound:
NaturalIdXrefDelegate:
case INSERT: {
naturalIdCacheAccessStrategy.insert( naturalIdCacheKey, pk );
( (EventSource) session() ).getActionQueue().registerProcess(
new AfterTransactionCompletionProcess() {
@Override
public void doAfterTransactionCompletion(boolean success, SessionImplementor session) {
final boolean put = naturalIdCacheAccessStrategy.afterInsert( naturalIdCacheKey, pk );
if ( put && justAddedToLocalCache && factory.getStatistics().isStatisticsEnabled() ) {
factory.getStatisticsImplementor().naturalIdCachePut(
naturalIdCacheAccessStrategy.getRegion().getName() );
>From what I've understood, both natural id caching and entity caching should behave in the same way.
Infinispan does not implement afterInsert() because it's not an asynchornous caching strategy, so natural id cache puts on insert are not currently being updated.
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
12 years, 9 months
Hibernate Shards ?
by Sanne Grinovero
While it doesn't happen every day, we sometimes have people asking
help on Shards on the forums.
Take this for example:
https://forum.hibernate.org/viewtopic.php?p=2453788#p2453788
The distribution does not contain such information, and has no other
dependencies. The changelog does not contain information about the
version, nor does the documentation. With luck I remember there used
to be a compatibility matrix on the homepage!
Bottomline, should Shards still be listed on the frontpage of
Hibernate.org as all other modules?
I think we should either move it in an "attic" area, or update it's
landing page to point out it's state of maintenance.
Cheers,
Sanne
12 years, 9 months
