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
Jira + GitHub
by Steve Ebersole
Hey everyone. A few months ago we had moved Hibernate Jira from using
FishEye to link in commits against GitHub to using Atlassian's "DVCS
Connector" plugin. Not even sure how many of you were aware but we had
been having a few problems with it (mainly not all commits showing up
automatically). I have been working with Atlassian to try and get that
corrected. Today we think those problems are all resolved.
If you notice any pushed commits that do not show up on the commits tab in
the Jira issue please let me know.
12 years, 2 months
Regression after upgrade to 4.1.7.Final
by Guillaume Smet
Hi,
We just upgraded to Hibernate 4.1.7.Final (from 4.1.6.Final) and we
have a pretty bad regression with 4.1.7 and Hibernate Search 4.1.1.
We have the following stack trace when saving an object:
Caused by: org.hibernate.HibernateException: Error while indexing in
Hibernate Search (before transaction completion)
at org.hibernate.search.backend.impl.EventSourceTransactionContext$DelegateToSynchronizationOnBeforeTx.doBeforeTransactionCompletion(EventSourceTransactionContext.java:186)
at org.hibernate.engine.spi.ActionQueue$BeforeTransactionCompletionProcessQueue.beforeTransactionCompletion(ActionQueue.java:662)
at org.hibernate.engine.spi.ActionQueue.beforeTransactionCompletion(ActionQueue.java:307)
at org.hibernate.internal.SessionImpl.beforeTransactionCompletion(SessionImpl.java:607)
at org.hibernate.engine.transaction.internal.jdbc.JdbcTransaction.beforeTransactionCommit(JdbcTransaction.java:105)
at org.hibernate.engine.transaction.spi.AbstractTransactionImpl.commit(AbstractTransactionImpl.java:175)
at org.hibernate.ejb.TransactionImpl.commit(TransactionImpl.java:75)
at org.springframework.orm.jpa.JpaTransactionManager.doCommit(JpaTransactionManager.java:512)
... 47 more
Caused by: java.lang.NullPointerException
at org.hibernate.engine.internal.StatefulPersistenceContext.getLoadedCollectionOwnerOrNull(StatefulPersistenceContext.java:851)
at org.hibernate.event.spi.AbstractCollectionEvent.getLoadedOwnerOrNull(AbstractCollectionEvent.java:75)
at org.hibernate.event.spi.InitializeCollectionEvent.<init>(InitializeCollectionEvent.java:36)
at org.hibernate.internal.SessionImpl.initializeCollection(SessionImpl.java:1799)
at org.hibernate.collection.internal.AbstractPersistentCollection$4.doWork(AbstractPersistentCollection.java:524)
at org.hibernate.collection.internal.AbstractPersistentCollection.withTemporarySessionIfNeeded(AbstractPersistentCollection.java:212)
at org.hibernate.collection.internal.AbstractPersistentCollection.initialize(AbstractPersistentCollection.java:520)
at org.hibernate.collection.internal.AbstractPersistentCollection.read(AbstractPersistentCollection.java:125)
at org.hibernate.collection.internal.PersistentBag.iterator(PersistentBag.java:266)
at org.hibernate.search.engine.spi.AbstractDocumentBuilder.appendContainedInWorkForInstance(AbstractDocumentBuilder.java:296)
at org.hibernate.search.engine.impl.WorkPlan$PerEntityWork.processContainedIn(WorkPlan.java:525)
at org.hibernate.search.engine.impl.WorkPlan$PerClassWork.processContainedInAndPrepareExecution(WorkPlan.java:297)
at org.hibernate.search.engine.impl.WorkPlan.processContainedInAndPrepareExecution(WorkPlan.java:144)
at org.hibernate.search.backend.impl.WorkQueue.prepareWorkPlan(WorkQueue.java:135)
at org.hibernate.search.backend.impl.BatchedQueueingProcessor.prepareWorks(BatchedQueueingProcessor.java:71)
at org.hibernate.search.backend.impl.PostTransactionWorkQueueSynchronization.beforeCompletion(PostTransactionWorkQueueSynchronization.java:86)
at org.hibernate.search.backend.impl.EventSourceTransactionContext$DelegateToSynchronizationOnBeforeTx.doBeforeTransactionCompletion(EventSourceTransactionContext.java:183)
... 54 more
I don't know if it's something obvious or if you need a self contained
test case to reproduce it.
I haven't created a JIRA because I don't know if it's an
incompatibility between Hibernate Search 4.1.1 and Hibernate 4.1.7 or
a real bug (either in HHH or HSEARCH).
Feel free to ping me for more information or any further action.
Thanks.
--
Guillaume
12 years, 2 months
Why do Services need to be Serializable?
by Sanne Grinovero
I just found this comment on org.hibernate.service.Service:
/**
* Marker interface for services.
* <p/>
* NOTE : All services must be {@link Serializable}!
*
* @author Steve Ebersole
*/
public interface Service extends Serializable {
What kind of bad things will happen to us if violating this recommendation?
In OGM we have for example connection pools managed in a Service, we
can hardly serialize that.
Sanne
12 years, 3 months
[OGM] @JoinColumns, @EmbeddedId & IN_ENTITY mode
by Guillaume SCHEIBEL
Hi guys,
I'm working on OGM-236 which consists to use by default the IN_ENTITY mode
for association storage strategy instead of COLLECTION.
I've just found out a little issue, when we use @JoinColumns over a
@OneToMany property to map an @EmbeddedID with the IN_ENTITY mode, the
navigation information are not stored directly into the document itself but
another document composed by the join columns as the _id and the navigation
information (in that case the IDs that the entity is related to).
Concretely, let's starting from this mapping:
https://github.com/hibernate/hibernate-ogm/blob/master/hibernate-ogm-core...
https://github.com/hibernate/hibernate-ogm/blob/master/hibernate-ogm-core...
https://github.com/hibernate/hibernate-ogm/blob/master/hibernate-ogm-core...
and run this test with the IN_ENTITY mode on (to make the switch, a
modification into MongoDBDatastoreProvider.configure() is needed)
https://github.com/hibernate/hibernate-ogm/blob/master/hibernate-ogm-core...
We can expect to have something like:
{
"_id": {
"author": "Guillaume",
"title": "There are more than 20 JUGs in France"
},
"content": "Great! Congratulations folks",
"labels": [
{ "id": NumberLong(5) }
]
}
It means this News is related to 1 Label of which ID is 5.
But due to @JoinColumns we got this (both documents are from the News
collection):
{
"_id": {
"author": "Guillaume",
"title": "There are more than 20 JUGs in France"
},
"content": "Great! Congratulations folks",
"labels": []
} {
"_id": {
"news_author_fk": "Guillaume",
"news_topic_fk": "There are more than 20 JUGs in France"
},
"labels": [{
"id": NumberLong(5)
}]
}
Of course at the loading, when the News seems not related to any Label
because the "labels" field is empty.
A workaround it to change the @JoinColumns from:
@JoinColumns({@JoinColumn(name="news_topic_fk", referencedColumnName =
"newsid.title", nullable = false) ,
@JoinColumn(name="news_author_fk", referencedColumnName =
"newsid.author", nullable = false)})
private List<Label> labels;
@JoinColumns({@JoinColumn(name="title", referencedColumnName =
"newsid.title", nullable = false) ,
@JoinColumn(name="author", referencedColumnName =
"newsid.author", nullable = false)})
private List<Label> labels;
Note that the new value of each @JoinColumn's name is the same as
referenced property from the @Embedded entity.
I see there are 2 fix possible for this issue:
- we can say in case of IN_ENTITY mode don't use @JoinColumns' name to
store the navigation property but the property from the referenced
column.
- at the loading, we can check also the documents created due to @JoinColumns
Personally, I would tend to the first approach which is more natural
in terms of storage and more readable.
What do you think ?
Let me know if you need more information.
Guillaume
12 years, 3 months
Re: [hibernate-dev] OGM-229 Beef up MongoDB documentation
by Emmanuel Bernard
Many thanks Guillaume, I am reviewing them and rephrasing here and
there. It looks good so far. I'll probably integrate it in a few hours
and we can improve from this base.
Emmanuel
On Sun 2012-09-23 21:46, Guillaume SCHEIBEL wrote:
> Hi guys,
>
> I've just updated the documentation with the association storage strategies
> and I also included comments from Emmanuel.
> Everything is available here:
> https://github.com/hibernate/hibernate-ogm/pull/138
>
> Thanks for the review
>
> Guillaume
12 years, 3 months
Re: [hibernate-dev] fixing 2 hibernate bugs
by Strong Liu
I'm on vacation this week, forwarding it to hibernate-dev mail list
On Sep 24, 2012, at 3:55 PM, mutaz kabbashi <mutazhkabbashi(a)gmail.com> wrote:
> hi Strong
>
> i am new here and i want to contribute to hibernate project so i start
> with simple bugs, so that i can understand the structure and coding
> conventions of hibernate
> i start with these 2 bugs
>
> 1- DB2 HQL insert statement (https://hibernate.onjira.com/browse/HHH-7558)
>
> the problem here is that during the Session Factory initialization
> the sqlFunctions register Long data type as (big_integer ),while
> DB2Dialect class register it as
> (bigint) so when hibernate trying to find the data type of
> (bigint) in SqlFunctions (big_integer) hibernate throw null Pinter
> Exception ,
> I change bigint to big_integer in DB2Dialect class and it works now
>
> 2- getForUpdateString() of HSQLDialect returns empty string
> (https://hibernate.onjira.com/browse/HHH-7479)
>
> The problem here is that HQL Data base didn't support (select for
> update) statement in hql version 1.8 but it support it now (from
> version 2.0)
> so i modify getForUpdate()@HSQLDialect class and it works now
>
> how can i commit my modifications (i already create my fork at git hub)
>
> thank you
-------------------------
Best Regards,
Strong Liu <stliu at hibernate.org>
http://about.me/stliu/bio
12 years, 3 months
