[Hibernate-JIRA] Commented: (HHH-1737) Add a ConnectionWrapper interface to allow access to the underlying connection from a BorrowedConnectionProxy
by Adrian Riley (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1737?page=c... ]
Adrian Riley commented on HHH-1737:
-----------------------------------
Maybe I'm being stupid here, but this doesn't seem to work.
Calling getWrappedConnection() results in a call to the invoke() method of BorrowedConnectionProxy, which then calls ConnectionManager.getConnection(). This returns the NewProxyConnection which wraps the underlying Oracle Connection instance, and not the underlying connection itself. Calling ArrayDescriptor.createArrayDescriptor passing this connection results in a ClassCastException, exactly as before.
Have I missed something?
> Add a ConnectionWrapper interface to allow access to the underlying connection from a BorrowedConnectionProxy
> -------------------------------------------------------------------------------------------------------------
>
> Key: HHH-1737
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1737
> Project: Hibernate3
> Type: Bug
> Components: core
> Versions: 3.1.1, 3.1.2, 3.1.3
> Environment: Hibernate 3.1.3, Oracle 9.2.0.4
> Reporter: Nick Reid
> Assignee: Steve Ebersole
> Fix For: 3.2.1
>
>
> The borrowConnection functionality now prevents us from accessing the native connection to perform necessary operations (LOB handling, OAQ integration). Instead of just returning a simple proxy the implements java.sql.Connection the proxy could additionally implement an interface that allows users to access the wrapped connection returned by the ConnectionManager.
> i.e.
> public interface BorrowedConnection extends java.sql.Connection
> {
> java.sql.Connection getTargetConnection()
> }
> public class BorrowedConnectionProxy implements InvocationHandler {
> private final ConnectionManager connectionManager;
> private boolean useable = true;
> public BorrowedConnectionProxy(ConnectionManager connectionManager) {
> this.connectionManager = connectionManager;
> }
> public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
> if ( "close".equals( method.getName() ) ) {
> connectionManager.releaseBorrowedConnection();
> return null;
> }
> if ( "getTargetConnection".equals( method.getName() ) ) {
> return connectionManager.getConnection();
> }
> // should probably no-op commit/rollback here, at least in JTA scenarios
> if ( !useable ) {
> throw new HibernateException( "connnection proxy not usable after transaction completion" );
> }
> try {
> return method.invoke( connectionManager.getConnection(), args );
> }
> catch( InvocationTargetException e ) {
> throw e.getTargetException();
> }
> }
> public static Connection generateProxy(ConnectionManager connectionManager) {
> BorrowedConnectionProxy handler = new BorrowedConnectionProxy( connectionManager );
> return ( Connection ) Proxy.newProxyInstance(
> Connection.class.getClassLoader(),
> new Class[] { BorrowedConnection.class },
> handler
> );
> }
> public static void renderUnuseable(Connection connection) {
> if ( connection != null && Proxy.isProxyClass( connection.getClass() ) ) {
> InvocationHandler handler = Proxy.getInvocationHandler( connection );
> if ( BorrowedConnectionProxy.class.isAssignableFrom( handler.getClass() ) ) {
> ( ( BorrowedConnectionProxy ) handler ).useable = false;
> }
> }
> }
> }
> We could always get access to the connectionManager field of the invocation handler via reflection, but this is not supportable or maintainable.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
18 years
[Hibernate-JIRA] Commented: (ANN-140) Discriminator column not supported with JOINED strategy
by Erwin Bolwidt (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/ANN-140?page=co... ]
Erwin Bolwidt commented on ANN-140:
-----------------------------------
I don't understand Gavin's stance on this issue.
Yes, Hibernate is very smart and its way of doing joined subclasses has superios performance over implementations that require a discriminator column.
But hibernate's algorithm doesn't prevent a discriminator column. In fact, Hibernate itself supports discriminator columns with joined subclasses, so why are you explicitly disallowing it in hibernate annotations?
It leaves users out in the cold who are using a legacy database; the only way to get around it is to not use annotations for the superclass and all subclasses.
In addition to that, even if a discriminator column never gives any performance bonuses, it still makes the database model more resilient. If for some reason (dbas mucking about the database by hand, other apps interfering with the direct use of sql) data ends up in multiple subclass tables, a discriminator column makes it possible to clean up the database, since it is the judge on what the intended subclass was.
Please change the three lines of code and make it possible to configure discriminator columns with joined subclasses using hibernate annotations.
> Discriminator column not supported with JOINED strategy
> -------------------------------------------------------
>
> Key: ANN-140
> URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-140
> Project: Hibernate Annotations
> Type: Bug
> Versions: 3.1beta6
> Environment: Hibernate 3.1rc2, Hibernate Annotations 3.1b6
> Reporter: Steven Grimm
>
>
> Section 9.1.27 of the EJB3 persistence public draft says, "The DiscriminatorColumn annotation is used to define the discriminator column for SINGLE_TABLE and JOINED mapping strategies." But Hibernate ignores the DiscriminatorColumn annotation when the mapping strategy is JOINED; when a JOINED entity is persisted, its discriminator column is not included in the SQL "insert" statement, resulting in a not-null constraint violation if the discriminator column is marked NOT NULL in the database.
> The JOINED strategy with discriminators is pretty ubiquitous in EJB3 sample code and tutorials out on the net, so lots of people are likely to run into this as they try out EJB3 for the first time. A few examples:
> http://www.oracle.com/technology/tech/java/oc4j/ejb3/howtos-ejb3/howtoejb...
> http://www.solarmetric.com/Software/Documentation/4.0.0EA/docs/full/html/...
> http://www.caucho.com/resin-3.0/amber/tutorial/cmp-inherit/index.xtp
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
18 years
[Hibernate-JIRA] Created: (EJB-240) attribute-override and embedded in orm.xml not working
by Thomas Risberg (JIRA)
attribute-override and embedded in orm.xml not working
------------------------------------------------------
Key: EJB-240
URL: http://opensource.atlassian.com/projects/hibernate/browse/EJB-240
Project: Hibernate Entity Manager
Type: Bug
Components: EntityManager
Versions: 3.2.0.ga
Environment: 3.2.0GA + HA 3.2.0GA + HEM 3.2.0GA
Reporter: Thomas Risberg
Embedding an Address class twice and need to override the column names. Using orm.xml and <embedded> plus <attribute-override> does not work while the same construct works using annotations. The orm.xml works in the RI.
<embeddable class="jpatest.Address">
<attributes>
<basic name="street"/>
<basic name="city"/>
<basic name="state"/>
<basic name="zip"/>
</attributes>
</embeddable>
<entity class="jpatest.Employee" metadata-complete="false" access="FIELD">
<attributes>
<id name="id"/>
<basic name="name"/>
<embedded name="homeAddress">
<attribute-override name="street">
<column name="home_street"/>
</attribute-override>
<attribute-override name="city">
<column name="home_city"/>
</attribute-override>
<attribute-override name="state">
<column name="home_state"/>
</attribute-override>
<attribute-override name="zip">
<column name="home_zip"/>
</attribute-override>
</embedded>
<embedded name="mailAddress">
<attribute-override name="street">
<column name="mail_street"/>
</attribute-override>
<attribute-override name="city">
<column name="mail_city"/>
</attribute-override>
<attribute-override name="state">
<column name="mail_state"/>
</attribute-override>
<attribute-override name="zip">
<column name="mail_zip"/>
</attribute-override>
</embedded>
</attributes>
</entity>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
18 years, 1 month
[Hibernate-JIRA] Moved: (ANN-502) Cannot fully disable integration with Hibernate Validator
by Emmanuel Bernard (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/ANN-502?page=all ]
Emmanuel Bernard moved HHH-2279 to ANN-502:
-------------------------------------------
Project: Hibernate Annotations (was: Hibernate3)
Key: ANN-502 (was: HHH-2279)
Component: validator
(was: metamodel)
Version: 3.2.0.cr2
(was: 3.2.0.cr2)
> Cannot fully disable integration with Hibernate Validator
> ---------------------------------------------------------
>
> Key: ANN-502
> URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-502
> Project: Hibernate Annotations
> Type: Improvement
> Components: validator
> Versions: 3.2.0.cr2
> Reporter: Jacek Chleborowicz
> Priority: Minor
>
>
> I use Hibernate Validator for application-level validation.
> I disabled pre-insert and pre-update event listeners from Hibernate Validator.
> I allow persisting data, which doesn't match validation rules defined by Hibernate Validator annotations.
> Unfortunately Hibernate Validator is used in metamodel construction and i cannot disable it.
> For example, if i use @NotNull annotation, i've got: PropertyValueException with message "not-null property references a null or transient value: ...", because @NotNull annotation is recognized in metamodel construction.
> There should be configuration property defining if Hibernate integrates with Hibernate Validator. It should enable/disable:
> - usage of Hibernate Validator in metamodel construction;
> - registration of Validator event listeners.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
18 years, 1 month
[Hibernate-JIRA] Created: (HHH-2278) joined-sbuclass + oneToMany eager lead to incorrect SQL
by Anthony Patricio (JIRA)
joined-sbuclass + oneToMany eager lead to incorrect SQL
-------------------------------------------------------
Key: HHH-2278
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2278
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.1
Environment: H 3.2.1
Reporter: Anthony Patricio
Priority: Minor
Attachments: bug.zip
Model:
Injury *--1 Person
Suspect extends Person (joined subclass)
Suspect 1--* Case (eager with fetch=join)
Part of the SQL generated when executing "from Injury":
from Person person0_
left outer join Suspect person0_1_
on person0_.id=person0_1_.PERSON_ID
left outer join Case cases1_
on person0_.id=cases1_.PERSON_ID
where person0_.id=?
should be:
from Person person0_
left outer join Suspect person0_1_
on person0_.id=person0_1_.PERSON_ID
left outer join Case cases1_
on person0_1_.id=cases1_.PERSON_ID
where person0_.id=?
A simple workaround is to define
Suspect 1--* Case (eager with fetch=select, instead og join)
I've attached a testcase (EJB3 + hbm)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
18 years, 1 month
[Hibernate-JIRA] Commented: (HHH-418) many-to-one relationship; proxy returned instead of the object
by Nico De Groote (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-418?page=co... ]
Nico De Groote commented on HHH-418:
------------------------------------
Same problem here.... we sometimes get a proxy returned instead of the desired object?
> many-to-one relationship; proxy returned instead of the object
> --------------------------------------------------------------
>
> Key: HHH-418
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-418
> Project: Hibernate3
> Type: Bug
> Components: core
> Versions: 3.0.1
> Environment: Hibernate 3.0.1, Ingres
> Reporter: Carwin Zimmermann
>
>
> We have recently upgraded from hibernate 2 to 3 and am getting inconsistent behaviour when using a many-to-one relationship.
> The data model consists of an account with transactions. There are many transactions in each account which is mapped as follows:
> <class name="wms.model.ac.water.AcWaterTransaction" table="ac_water_transaction" >
> ...
> <many-to-one name="AcWaterAccount" column="c_account_id" class="wms.model.ac.account.AcWaterAccount" />
> ...
> When an AcWaterTransaction is retrieved and the AcWaterAccount object is accessed via the 'getter', instead of getting the actual AcWaterAccount object, I get the proxy object called wms.model.ac.account.AcWaterAccount$$EnhancerByCGLIB$$9c0bd41f. All other many-to-one relationships in the same object behave in this manner.
> <many-to-one name="AcWaterAccount" column="c_account_id" class="wms.model.ac.account.AcWaterAccount">
> <many-to-one name="InCodeBalanceEffect" column="c_balance_effect_id" class="wms.model.in.code.InCode" />
> <many-to-one name="AcWaterProduct" column="c_product_id" class="wms.model.ac.water.AcWaterProduct" />
> <many-to-one name="MeMeterReading" column="c_meter_reading_id" class="wms.model.me.meter.MeMeterReading" />
> However, another identical relationship, used in the same way returns the expected object.
> <many-to-one name="BiChargeCat" column="c_charge_cat_id" class="wms.model.bi.charge.BiChargeCat" />
> All the loaded objects
> The exact same configuration under hibernate 2.x (for both objects) works as expected - we are consistently returned the real object, never the proxy.
> So, Hibernate 3.x behaves differently to 2.x. Secondly 3.x behaves inconsitently under that same circumstances.
> Irrespective of whether this is labeled a bug or a feature, it renders hibernate 3.x unusable.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
18 years, 1 month