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
1 month, 3 weeks
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
>
9 years, 10 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
10 years, 6 months
Thinking about Forge 2 plugins
by Emmanuel Bernard
We probably should think about what it would mean to help people get
started with our projects using Forge. The Eclipse integration looks
very impressive and very much how I wish I could work to add layers.
I'll add it to the team meeting agenda.
Emmanuel
Date: Mon, 21 Oct 2013 18:27:12 -0400 (EDT)
From: Lincoln Baxter <lbaxter(a)redhat.com>
To: The Core
Subject: The Forge 2 philosophy in 4 minutes
Check out the video describing Forge 2 and where we are headed:
http://www.youtube.com/watch?v=Dpou-FWWatI
Just a quick update on the Forge project. This video will show you what we've been working on for the past while: namely a new architecture to allow extreme embed-ability, and real code re-use between addons (using our Modular container, called Furnace) https://github.com/forge/furnace (based on JBoss Modules and Maven). It does not go into great detail into many of these things, but is more of a high-level overview of the goals and features.
So what does this mean for your project?
1) Primarily, this means that you'll be able to work with us to create tools for your project that run in all of our supported environments and IDEs. Ideally this tooling should be focused on getting users started with your projects quickly, so if you're interested in having a Forge plugin for your project, please send me an email off list, and we will get the process started. We are currently preparing for the launch of our new website, so it will probably still be a few months before we can do any intensive project addon development with teams.
2) What this means in reality is that you can deliver tools that will run in JBDS and the command-line (and eventually IntelliJ, and NetBeans, and Web IDE), without worrying about coordination with an actual product release. Your release cycle is completely independent of ours. (Unless you are waiting for a new feature that is not yet released.)
To learn more about Forge 2, please visit our github repository: https://github.com/forge/core#jboss-forge-20
Expect to hear more from us soon :) We want *YOU*... and your projects of course :)
--
Lincoln Baxter, III
JBoss, by Red Hat
lbaxter(a)redhat.com
"If you want something, you'll find a way; if you don't, you'll find an excuse."
12 years, 1 month
[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
12 years, 1 month
Use cases for many-to-many collection of proxies?
by Gail Badner
Are there real-world use cases where an initialized many-to-many collection should contain elements that are uninitialized proxies (HibernateProxy), rather than entity instances?
Currently, it is possible to configure this behavior using either:
<many-to-many ... fetch="select"/>
<many-to-many ... outer-join="false"/>
We are considering removing this capability if there are no real-world use cases.
Fetch profiles do not provide this level of granularity. The fetch style for the collection itself, but not its elements, can be configured using a fetch profile.
As far as I know, JPA does not provide this level of granularity either.
Please let us know if you are using this functionality.
Thanks,
Gail
12 years, 1 month
JPA 2.1 in WildFly 8
by Arun Gupta
Hello there...
I've a simple sample defined at:
https://github.com/arun-gupta/javaee7-samples/tree/master/jpa/listeners
This sample shows how different JPA entity listeners can be specified.
Deploying this sample in WildFly trunk gives the following error:
05:28:54,709 ERROR [org.jboss.msc.service.fail] (ServerService Thread
Pool -- 59) MSC000001: Failed to start service
jboss.persistenceunit."jpa-listeners.war#myPU":
org.jboss.msc.service.StartException in service
jboss.persistenceunit."jpa-listeners.war#myPU":
java.lang.IllegalStateException: JBAS016071: Singleton not set for
org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader@639b9ef8.
This means that you are trying to access a weld deployment with a
Thread Context ClassLoader that is not associated with the deployment.
at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:169)
[wildfly-jpa-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117)
[wildfly-jpa-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_45]
at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:463)
[wildfly-security-manager-1.0.0.Beta3.jar:1.0.0.Beta3]
at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:178)
[wildfly-jpa-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
Any suggestions on what is wrong ?
--
Blog: http://blog.arungupta.me
Twitter: http://twitter.com/arungupta
12 years, 1 month
Failure upon importing ORM sources into IDE
by Gunnar Morling
Hi,
When importing the ORM Gradle project into IntelliJ or Eclipse, I'm getting
the following error:
===
FAILURE: Build failed with an exception.
* Where:
Build file '[...]/hibernate-orm/hibernate-core/hibernate-core.gradle' line:
2
* What went wrong:
A problem occurred evaluating project ':hibernate-core'.
> Could not create plugin of type 'MatrixTestingPlugin'.
===
Did anyone get this before as well and knows how to circumvent it (I'll try
to disable this plug-in during the import)?
Thanks,
--Gunnar
12 years, 1 month
[HHH-8483] METAGEN merge into ORM
by Hardy Ferentschik
Hi,
I pushed a branch [1] to my local ORM repo which integrates the metamodelgen sources into ORM as per HHH-8483 [2].
The sources are under tooling/metamodel-generator and the commit history is kept. I did, however, squash several commits.
This includes in particular the commits from the maven release process, but also some other commits which were not linked
to Jira issues.
The current metamodelgen build is still independent from the overall ORM build. It is, however, already Gradle based
and all the test framework is now JUnit (instead of TestNG). This should make it quite easy to hook into the ORM build.
I will look into this next.
A few remaining questions:
* What should be the next version of the annotation processor? I guess it could just use the main ORM version, so
we would make a version jump from 1.3.0.Final to 4.3.x
* Should we move the docbook sources to the documentation module and create a new "book", next to devguide, manual
and quickstart? I guess there are pro and cons for each approach. I would lean towards moving the metamodelgen docs.
* Any thoughts on whether we should change the artefact it? Or should we just keep hibernate-jpamodelgen?
Once the build is integrated into ORM, we can merge the Jira project METAGEN into HHH and update the README of the
original metamodelgen repo to refer to the new location.
Thoughts?
--Hardy
[1] https://github.com/hferentschik/hibernate-orm/compare/HHH-8483
[2] https://hibernate.atlassian.net/browse/HHH-8483
[3] https://github.com/hibernate/hibernate-metamodelgen
12 years, 1 month
[OGM] Option identity
by Emmanuel Bernard
Gunnar has I had a long discussion and disagreement on the behavior of Option in Hibernate OGM that we could not resolve. We would like your feedback.
I did design Option to represent three key concepts:
- an option family - for example named query
- an option per se - for example the combination of the named query family and the query name
- an option value - for example the named query value (the HQL)
These notions used to be separated in a previous incarnation but for the sake of simplification, we decided to merge option and option value.
So when I designed Option I added the notion of option identifier that combined with an option class (the family) would uniquely identify an option. This notion is represented by getOptionIdentifier() which is used by equals() and hashCode(). The idea is that an Option instance uniquely identifies an option and that we could detect when a user tries to define the same option several times (with or without different values).
We have two kinds of options:
- generic options like named query that required an additional key to be uniquely identified
- unique options like show_sql where the option family and the option are one and the same thing
In the unique option case, a UniqueOption subclass force the implementation of getOptionIdentifier so that equals / hashCode are true if the same option / option family are requested.
A goal of getOptionIdentifier() was to free the Option implementor from thinking too much about the equals() / hashCode implementation and just focus on the option identity.
Now Gunnar had a concern when he experimented with unique options
class ShowSql extends UniqueOption {
private String value;
public ShowSql(String value) {
this.value = value;
}
public static ShowSql TRUE = new ShowSql("true");
public static ShowSql FALSE = new ShowSql("false");
}
In this situation, ShowSql.equals(ShowSql.FALSE) == true and that bothers him.
So he changed the implementation of Option / UniqueOption to behave like I previously explained for generic options but to properly return ShowSql.equals(ShowSql.FALSE) == false. To do so, he removed getOptionIdentity() and manually ask (Unique)Option implementors to implement equals. In his example equals for ShowSql would be based on the value.
So we are at an impasse.
I hate his approach as the equals behavior is inconsistent between generic options and unique options. It's very confusing for an Option implementor to figure out what equals should do. And ice on the cake, the implementor has to implement equals / hashCode instead of delegating that to the superclass: more code, more opportunities to screw it up.
To me the fact that ShowSql.equals(ShowSql.FALSE) == true is indeed inelegant but AFAIAC is a degenerate case and shifts the identity from Option to Option + Option Value which is useless.
Gunnar cannot figure out what I am even saying and to him equals() should behave naturally period and the hell with consistency.
I see four ways out:
1. we stay how it is today with the weird equals behavior in case of constants and keep the concept that an Option is not identified by its value.
2. we move to Gunnar's position that an Option is uniquely identified by its family + value for unique options and keep generic options identity by family + key (and not value)
3. we move to Gunnar's position but all the way: an Option is uniquely identified by its family + value both for generic and unique options
4. we fall back to differentiate in the type system option family, option key, and option value.
So what do you guys all think of this problem?
Emmanuel
12 years, 1 month
