IP banned from forum
by Gunnar Morling
Hi,
Is anyone banning users from the forum? I am getting "A ban has been
issued on your IP address."
I don't think banning by IP is a good strategy as many users will have
dynamic IPs from their hoster's shared pool, so it's a random game to
hit an IP previously banned due to some other user's spam.
Thanks,
--Gunnar
3 weeks, 6 days
New CI machine preview
by Sanne Grinovero
You're all welcome to play with http://54.225.162.168/
however please keep these in mind:
- it's not the final machine: don't put too much effort in creating
nice build scripts as we'll reset it to clean state soon. We *might*
be able to store jobs defined so far, but we might choose not to.
- domain name should be coming: ci.hibernate.org ..not sure when, got
no replies so far from.
- authentication: just click on login, it will use OAuth2 to request
your identity via your GitHub account. Permissions to create new jobs,
edit existing jobs, run a build manually depend on your github account
be part of the Hibernate organization (or not, in which case you have
read only status)
At this stage I'd like to get a feeling if the hardware is powerful
enough, and also we need to select which other plugins we want to use,
I'm looking especially to:
- static analysis reports
- pull requests integration
both are relatively undefined, we can of course start simple and
improve later.. just checking this fits basic needs now.
Sanne
3 months, 1 week
JSR 354 - Money and Currency
by Steve Ebersole
So it sounds like JSR 354 may not be included in Java 9. Do we still want
to support this for ORM 5? I am not sure if "moneta" requires Java 9...
9 years, 12 months
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
>
10 years
Re: [hibernate-dev] [hibernate-orm] HHH-7572 - Develop API for load-by-multiple-ids (#1136)
by Konstantin Bulanov
Hello Steve, as you asked moving our discussion about HHH-7572 in dev mail
list.
Regarding you question, in current architecture and implementation we have
the following point to perform entity persistence customization.
Annotation:
https://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/annotatio...
which allows us to specify our own implementation of
https://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/persister....
One of its methods is:
Object load(Serializable id,
Object optionalObject,
LockMode lockMode,
SessionImplementor session)
throws HibernateException
Load an instance of the persistent class.
and
Object load(Serializable id,
Object optionalObject,
LockOptions lockOptions,
SessionImplementor session)
throws HibernateException
Load an instance of the persistent class.
These two methods allows to specify you own Loader implementation to load
Entity by IDS,
in mentioned issue this part of contract was ignored by changing call
sequence on loading by multiple ids.
By Single id;
org.hibernate.internal.SessionImpl#get->IdentifierLoadAccessImpl->org.hibernate.internal.SessionImpl.IdentifierLoadAccessImpl#load->org.hibernate.event.spi.LoadEventListener#onLoad->org.hibernate.event.internal.DefaultLoadEventListener#loadFromDatasource->org.hibernate.persister.entity.EntityPersister#load
By Multiple id:
org.hibernate.internal.SessionImpl#byMultipleIds->org.hibernate.internal.SessionImpl.MultiIdentifierLoadAccessImpl#multiLoad->org.hibernate.loader.entity.DynamicBatchingEntityLoaderBuilder#multiLoad
So in new API for multiple load we lose at least 2 possible extension
points: onLoadEvent, Persister.load (here we could customize loader -
specify our own instead hardcoded one)
>From my point of view there should be the same approach to get entities by
ID(independent multiple or single).
So which one approach is correct and future-proof for Single id or Multiple
Ids?
20 нояб. 2015 г. 18:19 пользователь "Steve Ebersole" <
notifications(a)github.com> написал:
> Customize how? Loader still calls into the persister. Persisters and
> Loaders have a back-and-forth synergy.
>
> Also please discuss this on the hibernate-dev mailing list so others can be
> involved.
>
> On Fri, Nov 20, 2015 at 7:15 AM Konstantin Bulanov <
> notifications(a)github.com>
> wrote:
>
> > Hello Steve, could you be so kind to advice why we have different
> behavior
> > for loading by single id and multiple ids?
> >
> > In Case of single id, loading is going through
> > session->IdentifierLoadAccess->event->persister->Loader
> > In Case of multiple ids, loading is going through
> > session->MultiIdentifierLoadAccess->Loader
> >
> > So in case of load by single id it is possible to cutomize loading of
> > Entify using persister, but in new introduced API we lost this
> posibility.
> >
> > —
> > Reply to this email directly or view it on GitHub
> > <
> https://github.com/hibernate/hibernate-orm/pull/1136#issuecomment-158400273
> >
> > .
> >
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/hibernate/hibernate-orm/pull/1136#issuecomment-158413356>
> .
>
10 years
Oracle12cDialect identity support
by Gail Badner
Oracle12cDialect was added in 5.0 by HHH-9044. Unfortunately there are
problems with the new identity support that Oracle12cDialect introduced
(HHH-9983). The fix for HHH-9983 involved SPI changes, so it was applied to
master for 5.1 (only).
A couple of weeks ago, Andrea found that identities seemed to work using
5.0 when running BulkManipulationTest using Oracle JDBC 12.1.0.1.0. At the
same time it failed for me in the same way as HHH-9983 using 12.1.0.2.0.
Then Andrea and I switched the JDBC versions (Andrea tried 12.1.0.1.0; I
tried 12.1.0.2.0) and we were both able to run BulkManipulationTest
successfully. This was very strange, especially since we were using the
same Oracle instance, each using a different user. I didn't see any
difference in how we were setting Hibernate properties. Several days later,
I tried Oracle JDBC 12.1.0.2.0 again, but BulkManipulationTest was failing
again in the same way as HHH-9983.
Does anyone know how to get Oracle12cDialect's identity support to work for
5.0 reliably? Is there some version of Oracle JDBC or DB configuration that
is required?
If so, please let me know. The rest of this email assumes it is not
possible. If I'm missing some configuration detail, then just ignore the
rest of this message.
When the unit tests are run using Oracle12cDialect on 5.0, there are many
failures:
* tests with entities explicitly mapped to use an identity fail; these
failures did not happen in 4.3 using Oracle10gDialect because these tests
where skipped (because Oracle10cDialect#supportsIdentityColumns returns
false)
* use @GeneratedValue with default strategy or use hbm mapping for ID
<generator class="native"/>; these failures did not happen in 4.3 because
the native generator for Oracle10gDialect uses a sequence; the native
generator for Oracle12cDialect uses an identity.
Also, starting in 5.0, when using Oracle 12c, StandardDialectResolver will
automatically resolve to Oracle12cDialect if the dialect is not explicitly
mapped. Previously it would have resolved ot Oracle10gDialect.
I would be OK with changing the native generator in 5.0 from sequence to
identity if identities were working properly. I think it will cause
confusion when applications break. To get things working with 5.0,
applications will need to explicitly set the dialect to Oracle10gDialect,
extend Oracle12cDialect to disable identity support, or change ID mappings
to specify sequences.
Here are some alternatives to get things working.
Alternative A:
1) for 5.0 through 5.x override Dialect#getNativeIdentifierGeneratorClass
to return SequenceStyleGenerator.class; I suggest the change for 5.x
because I don't think it would be an acceptable to change the native
generator for Oracle12cDialect from using a sequence to using an identity
in 5.x;
2) for 5.0 only, remove support for identities;
3) for 6.0, if desireable, extend Oracle12gDialect (or whatever is current
at that time) to change the native generator to use an identity.
Alternative B:
1) for 5.0 through 5.x, leave Oracle12cDialect as is, and add a new dialect
with native generator that uses a sequence (i.e.,
Oracle12cNativeSequenceGeneratorDialect or something else that is not so
ugly);
2) for 5.0 through 5.x, change StandardDialectResolver to automatically
resolve to Oracle12cNativeSequenceGeneratorDialect for Oracle 12g server.
Alternative C:
1) for 5.0 through 5.x, change native generator for Oracle12cDialect to use
sequence; leave identity support as is (broken in 5.0; fixed in 5.1);
2) for 5.0 through 5.x, add a new dialect with native generator that uses
an identity (Oracle12cNativeIdentityGeneratorDialect or something else that
is not so ugly).
3) change StandardDialectResolver to automatically resolve to
Oracle12cDialect for Oracle 12g server.
I prefer alternative A. Alternatives B and C involve maintaining 2 dialects
for the same Oracle version; I would think that one of them would be
deprecated moving forward.
Thoughts?
Thanks,
Gail
10 years
HHH-5855 bug report and a possible fix
by Vlad Mihalcea
Hi guys
I decided to spend some time to investigate the infamous HHH-5855 (
https://hibernate.atlassian.net/browse/HHH-5855 ) bug and this is my
report.
One of the first thing that I noticed is that Sets are fine, while this bug
only replicates with bidirectional Bags.
After some hours of debugging and logging (since debugging triggers
collection initialization), I found the culprit.
In the org.hibernate.type.TypeHelper.replace(Object[] original, Object[]
target, Type[] types, SessionImplementor session, Object owner, Map
copyCache) method, when copying the cached entity state (which contains the
newly added child entity along with its identifier) onto the original
collection:
copied[i] = types[i].replace( original[i], target[i], session, owner,
copyCache );
inside the org.hibernate.type.CollectionType.replace(Object[] original,
Object[] target, Type[] types, SessionImplementor session, Object owner,
Map copyCache) method there is this check:
if ( !Hibernate.isInitialized( original ) ) {
return target;
}
For Sets, the collection is always initialized because of this line inside
the add() method of the org.hibernate.collection.internal.PersistentSet:
final Boolean exists = isOperationQueueEnabled() ?
readElementExistence( value ) : null;
Because of the the readElementExistence( value ) call the Set is always
initialized and upon triggering the flush, the newly added Entity being
already managed it will be left alone.
For PersistentList the aforementioned check is false and the replace never
occurs, hence the transient entity lingers in the persistence context and
the flush will trigger another insert, so we get duplicates.
To make the Bag behave like the Set, all we need to do is to change the add
method like this:
public boolean add(Object object) {
initialize(false);
if ( !isOperationQueueEnabled() ) {
write();
return bag.add( object );
}
else {
queueOperation( new SimpleAdd( object ) );
return true;
}
}
but then four tests will fail:
org.hibernate.test.legacy.MasterDetailTest > testQueuedBagAdds FAILED
java.lang.AssertionError at MasterDetailTest.java:1068
org.hibernate.test.unionsubclass.UnionSubclassTest > testUnionSubclass
FAILED
org.hibernate.ObjectDeletedException at UnionSubclassTest.java:364
org.hibernate.test.version.VersionTest > testCollectionNoVersion FAILED
java.lang.AssertionError at VersionTest.java:118
org.hibernate.test.version.VersionTest > testCollectionVersion FAILED
java.lang.AssertionError at VersionTest.java:79
3 of them fail because we expect the List not to be initialized and
the UnionSubclassTest fails
for a doubtful reason (we attempt to delete an entity which is still
referenced).
Basically, such a change will finally fix this issue and the Sets and Lists
will behave consistently. Since you know the reasons behind the difference
in how Sets and Lists are initialized, we need to discuss if this change is
appropriate or we should address this issue differently.
I have a branch on my fork with a test that replicates this issue and that
the proposed change manages to fix it:
https://github.com/vladmihalcea/hibernate-orm/tree/feature/hhh5855
Let me know what you think and let's discuss it further.
Vlad
10 years, 1 month
