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
[OGM] Hibernate OGM @ Devoxx
by Guillaume SCHEIBEL
Hello,
After SoftShake (and few JUGs), I'm proud (and kind of exited) to announce
my Tool In Action titled "a hint of NoSQL into my Java EE" has been
approved.
See you there :)
Guillaume
11 years, 1 month
[Search] Dynamic sharding configuration
by Hardy Ferentschik
Hi,
I am currently working on HSEARCH-471 [1] - dynamic sharding. The work is built on Emmanuel's prototype and you find the current code on my fork [2].
Right now I am wondering about how to configure (dynamic) sharding. Here is how things worked prior to dynamic sharding. Basically there two properties
driving the shard configuration:
- hibernate.search.[indexName].sharding_strategy
- hibernate.search.[indexName].sharding_strategy.nbr_of_shards
The first property determines the implementation class of IndexShardingStrategy and the second the number of shards to create. So far we had two implementations
of IndexShardingStrategy, namely NotShardedStrategy and IdHashShardingStrategy.
To configure sharding it was enough to set nbr_of_shards to a value > 1. This would automatically select IdHashShardingStrategy and shard depending on the configured
number of shards. The idea was to make it simple to for the user and only require a single configuration change to enable sharding.
However, it creates inconsistencies. For example what if I select NotShardedStrategy and nbr_of_shards >1?
Or I set a custom sharding strategy which does not care about the number of shards?
IMO the important factor is to set the right sharding strategy and nbr_of_shards should just be a (optional) parameter to the sharding strategy.
With dynamic sharding things get more complicated. Right now you configure dynamic sharding by setting 'nbr_of_shards' to the literal 'dynamic'. This selects under the hood the
right IndexShardingStrategy (DynamicShardingStrategy). I find it misleading on multiple levels. First 'dynamic' is not a number and secondly I want to configure a strategy
not the number of shards. It is also inconsistent with how we select/configure other pluggable components in Search. For that reason I suggest:
- The type of sharding is configured via setting hibernate.search.[indexName].sharding_strategy. 'nbr_of_shards' is a parameter which gets passed to the strategy and which
might get ignored depending on the sharding implementation. Implementations are free to check the property and e.g. print out a warning if the settings does not apply to them
- We introduce short names for the provided sharding strategies - 'none', 'id-hash', 'dynamic'. This will avoid the need to reference concrete implementation classes
- For dynamic sharding we have the additional sub-property 'shard_identity_provider' which specifies the ShardIdentifierProvider (new contract needed for dynamic sharding).
This property is only relevant for dynamic sharding and will be handled in the same way as 'nbr_of_shards'
Thoughts?
--Hardy
[1] https://hibernate.atlassian.net/browse/HSEARCH-472
[2] https://github.com/hferentschik/hibernate-search/compare/HSEARCH-472
11 years, 2 months
Decoupling indexed types from their class definitions
by Sanne Grinovero
Some other projects use Hibernate Search - specifically the engine
module - to bridge their domain model to a Lucene index and take
advantage of its high performance low-level integration with Lucene.
This is generally achieved by indexing a "valueholder" object which
has most logic to create a custom o.a.l.Document in a top level
@ClassBridge, or by using some custom FieldBridges, but has some
strong limitations and feels more like a hack.
In Hibernate Search 5.0 we will make this more flexible, so to move
away from an annotated-entities index engine only to make it easier to
index objects whose "schema" is more flexible than the contraints
imposed by the staticness of a compiled Java class.
We've discussed however to introduce some of these features right now
(in version 4.4), so that we can start exploring the direction
gradually and get some early feedback. In particular what seems to be
troublesome is to implement multiple "user types" using the same type
(java type) as valueholders: the trouble is to filter on the correct
user type where the Hibernate Search APIs expect - as basic filtering
strategy - a java Class instance, or simply to have the flexibility to
configure separate backends for each user type.
So this first refactoring [HSEARCH-1402] will be about moving the
*internal* contract - without changing public APIs - to use a
different identification than the current Class when we lookup for
indexing information for a specific indexed type.
Comments very welcome.
Sanne
- https://hibernate.atlassian.net/browse/HSEARCH-1379 Explicit support
for indexing free-form (dynamic) entities
- https://hibernate.atlassian.net/browse/HSEARCH-1402 Allow explicit
user control of ProjectionConstants.OBJECT_CLASS value during indexing
- https://hibernate.atlassian.net/browse/HSEARCH-1404 More flexibility
than just Class to identify indexing metadata
11 years, 2 months
[HV] Extending ParameterNameProvider contract for other element types
by Gunnar Morling
Hi,
On SO [1], a user asked whether it's possible to report custom names for
property constraint violations, e.g. "nm" as retrieved from the annotation
in this case:
@JsonProperty("nm")
@NotNull
final public String name;
At the moment that's not possible with HV, but one might think about a
contract similar to ParameterNameProvider which returns the reported names
for properties (or even custom names to be used instead of the constants
"<return-value>" and "<cross-parameter>").
It's the first time I came across this requirement but adding support for
this should not be too complex and it might be helpful to some. Any
thoughts?
--Gunnar
[1]
http://stackoverflow.com/questions/18878868/hibernate-validator-and-jacks...
11 years, 2 months
checkNullability when deleting an entity
by Steve Ebersole
Anyone have compelling reasons to continue to call
org.hibernate.engine.internal.Nullability#checkNullability when deleting
an entity?
To a lesser degree, how about reasons for calling
org.hibernate.engine.internal.ForeignKeys.Nullifier#nullifyTransientReferences
when deleting?
11 years, 2 months
[Search] Dynamic Sharding the second
by Hardy Ferentschik
Hi,
here comes a follow up on my previous email regarding configuration of dynamic sharding.
Now I would like to get some feedback on ShardIdentifierProvider. This interface was added for dynamic sharding on
top of DynamicShardingStrategy. Gunnar and I had a discussion around it today [1] and we came to the conclusion that
this interface is actually not needed and just adds confusion in the API.
Really ShardIdentifierProvider is a IndexShardingStrategy in disguise. Add 'forAddtion' and 'forDeletion' to the two 'getShardIdentifier' methods
and you have (almost) an IndexShardingStrategy. The problem seems to be, that in order to implement dynamic sharding the
IndexManagerHolder and EntityIndexBinding are needed. IndexShardingStrategy#initialize does not provide access to these objects which maybe
led to the current design.
In DynamicShardingStrategy this is taken care of by passing IndexManagerHolder and EntityIndexBinding as part of the constructor arguments.
Otherwise DynamicShardingStrategy is just a very thin wrapper delegating to the ShardIdentifierProvider.
If the current IndexShardingStrategy#initialize method would get passed the required information for dynamic sharding, there would be no need
for an additional interface like ShardIdentifierProvider. Dynamic sharding could be implemented with the existing extension points and implementations
would fit better into the current pattern of providing custom implementations.
What we could do is to make DynamicShardingStrategy an interface extending IndexShardingStrategy and adding a second initialise contract
of sorts. This would keep backwards compatibility, but also allow for dynamic sharding by users implementing DynamicShardingStrategy.
At the downside the user would have to write a bit more code, but I think that's acceptable given the more consistent approach towards sharding.
Thoughts?
--Hardy
P.S. In case you guys think that we really should hold on to ShardIdentifierProvider, I would at least suggest to either rename
the two 'getShardIdentifier' methods adding 'forAddition' and 'forDeletion' or even collapse the two into a single method (not sure
whether this is easily possible)
[1] http://transcripts.jboss.org/channel/irc.freenode.org/%23hibernate-dev/20...
11 years, 2 months
Should we deprecate @Similarity
by Sanne Grinovero
Discussing about some hibernate-search-engine complexities with Hardy
on IRC, we came to the agreement that the way @Similarity behaves
today was a mistake, so we're proposing to deprecate it in 4.4.
Reasoning follows.
There is a strong requirement in Lucene that all operations on the
same index need to use the same Similarity implementation. We infer
the org.apache.lucene.search.Similarity to be used on a specific index
from either:
- the similarity property from the configuration file, which is
positioned on an index name
- the @Similarity annotation positioned on an indexed entity
The trouble is about all these options needing to be consistent; first
problem is there isn't a precedence rule: if one of them is not
specified, we assume the user is using the other way to configure
things. But also different entities might be sharing the same index,
which leads to needing to verify that at least the user isn't
specifying some contradictory option.
This all gets more confusing when you introduce the notion of
dynamically added new entities (a feature used by Infinispan) and/or
Dynamic Sharding, in which the properties of some indexes might
conflict with the specified @Similarity, but we might notice this only
at runtime rather than at bootstrap. Failing to load a class at this
point is far more annoying to the users than to fail the health-check
at bootstrap time.
So the proposal:
drop the @Similarity annotation and use properties exclusively.
Properties are more suited for this as they are set on a per-index
base, which is what matters in this case.
Downside:
I guess lots of people where using a single index per type, and for
those there was no danger to simply specify a @Similarity. We lose
this straight-forward way of things, but I'd argue that if you're in
the business of specifying a custom Similarity, you're a very advanced
user and wouldn't mind setting a one-liner in your configuration file.
Do we agree?
Sanne
11 years, 2 months
