[Hibernate-JIRA] Created: (HHH-4112) HibernateProxy enhanced POJOs lose method annotations
by David Green (JIRA)
HibernateProxy enhanced POJOs lose method annotations
-----------------------------------------------------
Key: HHH-4112
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4112
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.2.0.ga
Reporter: David Green
Using FetchType.LAZY on an association can result in POJO entities being enhanced via JavassistProxyFactory or CGLIBProxyFactory. The resulting class overrides all declared accessors and mutators (get/set methods) in the original POJO. Those overridden methods lose any annotations that were specified on the original POJO.
The result is that unsuspecting code looking for annotations on POJO accessors won't find any annotations.
For example, if I have an @Entity POJO called Resident, the following JUnit test will fail for both CGLIBProxyFactory and JavassistProxyFactory:
{code:Java}
public void testCGLibProxy() throws HibernateException, SecurityException, NoSuchMethodException {
doTest(new CGLIBProxyFactory());
}
public void testJavassistProxy() throws HibernateException, SecurityException, NoSuchMethodException {
doTest(new JavassistProxyFactory());
}
private void doTest(ProxyFactory proxyFactory) throws NoSuchMethodException {
HashSet proxyInterfaces = new HashSet();
proxyInterfaces.add( HibernateProxy.class );
proxyFactory.postInstantiate("Resident", Resident.class, proxyInterfaces, Resident.class.getDeclaredMethod("getId"), Resident.class.getDeclaredMethod("setId",Long.class), null);
HibernateProxy hibernateProxy = proxyFactory.getProxy(resident.getId(), session);
assertTrue(hibernateProxy instanceof Resident);
System.out.println("Hibernate proxy name: "+hibernateProxy.getClass().getName());
assertNotNull(Resident.class.getDeclaredMethod("getMaritalStatus").getAnnotation(Required.class));
assertNotNull(hibernateProxy.getClass().getDeclaredMethod("getMaritalStatus").getAnnotation(Required.class));
}
{code}
--
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
14 years, 7 months
[Hibernate-JIRA] Created: (HHH-2575) Query results are mapped to object array incorrectly when there is column ambiguity and aliases are not used
by Mike Hoeffner (JIRA)
Query results are mapped to object array incorrectly when there is column ambiguity and aliases are not used
------------------------------------------------------------------------------------------------------------
Key: HHH-2575
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2575
Project: Hibernate3
Issue Type: Bug
Components: query-sql
Affects Versions: 3.2.2
Environment: Hibernate 3.2.2 + MySQL 5.0.22 + MySQL Connector/J 5.0.5. Reproduced with HSQLDB 1.8.0.7.
Reporter: Mike Hoeffner
Priority: Minor
Attachments: ResultsNotEffectedByAliasesTest.java
I had a SQL (not HQL) query that basically looked like this:
select a.name, a.seq, b.name, b.seq from foo a, foo b;
and I noticed that the results obtained through list() -> (Object[]) get(i) -> row[0], row[1], row[2], row[3]
did not correspond to what I saw when manually running the query without Hibernate involved. row[2] always had the same values as row[0] and row[3] always had the same values as row[1].
When I tried adding aliases so that it became:
select a.name as a_name, a.seq as a_seq, b.name as b_name, b.seq as b_seq from foo a, foo b;
then the results matched what I expected. So having aliases in the SQL modified the results that were returned even though I was looking up the value from each column by its index / position instead of by its name / alias.
Attached is a test case that will reproduce this.
--
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
14 years, 7 months
[Hibernate-JIRA] Created: (HHH-2661) Second-level cache is used after Session.setCacheMode(CacheMode.IGNORE)
by Anders Wallgren (JIRA)
Second-level cache is used after Session.setCacheMode(CacheMode.IGNORE)
-----------------------------------------------------------------------
Key: HHH-2661
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2661
Project: Hibernate3
Issue Type: Bug
Components: caching (L2)
Affects Versions: 3.2.4.sp1
Environment: Windows Vista
MySQL 5.0
Reporter: Anders Wallgren
I'm doing some bulk importing and want to disable the L2 cache, so I call Session.setCacheMode(CacheMode.IGNORE) before doing any work.
However, the entities I'm creating still end up in the cache. It seems that org.hibernate.action.CollectionAction isn't doing the correct check to determine when to cache -- it only check for the existence of a configured cache, but doesn't check whether caching is enabled in the session.
For example, from CollectionAction.beforeExecutions:
public final void beforeExecutions() throws CacheException {
// we need to obtain the lock before any actions are
// executed, since this may be an inverse="true"
// bidirectional association and it is one of the
// earlier entity actions which actually updates
// the database (this action is resposible for
// second-level cache invalidation only)
if ( persister.hasCache() ) {
final CacheKey ck = new CacheKey(
key,
persister.getKeyType(),
persister.getRole(),
session.getEntityMode(),
session.getFactory()
);
lock = persister.getCache().lock(ck, null);
}
}
Shouldn't "if ( persister.hasCache() )" be persistence.hasCache && getSession.getCacheMode.isPutEnabled(), or something along those lines?
--
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
14 years, 7 months
[Hibernate-JIRA] Created: (HHH-3899) Inconsistencies when processing changes to read-only and immutable entities
by Gail Badner (JIRA)
Inconsistencies when processing changes to read-only and immutable entities
---------------------------------------------------------------------------
Key: HHH-3899
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3899
Project: Hibernate Core
Issue Type: Bug
Reporter: Gail Badner
I've noticed that there are inconsistencies when read-only and immutable entities are modified. I've added some unit tests to org.hibernate.test.immutable.ImmutableTest and created org.hibernate.test.readonly.ReadOnlyVersionedNodesTest which show the inconsistencies.
The same behavior is seen in Branch_3_2, Branch_3_3, and trunk.
The inconsistencies in org.hibernate.test.immutable.ImmutableTest are:
ImmutableTest.testImmutable():
If an immutable entity with an immutable collection is associated with the session, an addition to the immutable collection is ignored
ImmutableTest.testImmutableCollectionWithUpdate:
If Session.update() is used to associate an immutable entity with an addition made to its immutable collection, then Hibernate detects that the reassociated entity has a dirty collection and HibernateException is thrown
ImmutableTest.testImmutableCollectionWithMerge:
If Session.merge() is used to associate an immutable entity with an addition made to its immutable collection, then, later when the transaction is committed, Hibernate detects that an immutable collection was changed and HibernateException is thrown
The inconsistencies in org.hibernate.test.readonly.ReadOnlyVersionedNodesTest are:
ReadOnlyVersionedNodesTest.testAddNewChildToReadOnlyParent():
If a read-only entity is associated with the session and a new child entity is added to collection, the new child entity is not persisted when the transaction is committed
ReadOnlyVersionedNodesTest.testUpdateParentWithNewChildCommitWithReadOnlyParent():
ReadOnlyVersionedNodesTest.testMergeDetachedParentWithNewChildCommitWithReadOnlyParent():
ReadOnlyVersionedNodesTest.testGetParentMakeReadOnlyThenMergeDetachedParentWithNewChildC():
If Session.merge() or Session.update() is used to associate a parent entity with a new child entity in its collection, and that parent entity is made read-only, then, later when the transaction is committed, the new child entity is persisted and it is associated with the parent
ReadOnlyVersionedNodesTest.testAddNewParentToReadOnlyChild():
If a read-only entity is associated with the session and a new parent entity is assigned, the new parent entity is not persisted when the transaction is committed
ReadOnlyVersionedNodesTest.testUpdateChildWithNewParentCommitWithReadOnlyChild():
If Session.update() is used to associate a child entity with a new parent entity, and the child entity is made read-only, later, when the transaction is committed, the new parent entity is persisted, but it is not associated with the child
ReadOnlyVersionedNodesTest.testMergeDetachedChildWithNewParentCommitWithReadOnlyChild():
ReadOnlyVersionedNodesTest.testGetChildMakeReadOnlyThenMergeDetachedChildWithNewParent():
If Session.merge() is used to associate a child entity with a new parent entity, and the child entity is made read-only, later, when the transaction is committed, the new parent entity is persisted, but it is not associated with the child; in addition the version on the parent is incremented.
If any of these results appear to be due to a bug, the test name should be changed to end in FailureExpected until the bug is fixed.
--
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
14 years, 7 months
[Hibernate-JIRA] Created: (HCANN-7) Hibernate interprets relation as embedding
by Lucius Gregory Meredith (JIRA)
Hibernate interprets relation as embedding
------------------------------------------
Key: HCANN-7
URL: http://opensource.atlassian.com/projects/hibernate/browse/HCANN-7
Project: Hibernate Commons Annotations
Issue Type: Bug
Affects Versions: 3.2
Environment: Mac OS X (leopard); Java 1.5 or 1.6; MySQL, HSQLDB
Reporter: Lucius Gregory Meredith
Hibernate interprets JPA annotations
@Entity
...
public class ... {
...
@OneToOne
@JoinColumn
<MethodDecl>
...}
as indication to embed the referenced entity, rather than use the key.
For code sample see http://svn.biosimilarity.com/src/open/codesamples/trunk/hibernate
Instructions for use:
i included the target dir in the repo to speed up investigation, but you can just blow that away and build from scratch. The example is currently written to Java1.6, but also exhibits the same behavior under Java1.5. To run the example
> svn co http://svn.biosimilarity.com/src/open/codesamples/trunk/hibernate
...
> env PATH=<path-to-java1.6>:$PATH JAVA_HOME=<path-to-java1.6> mvn clean compile process-classes
If you switch comment and decl at line 22 in src/main/java/maxb/hbex2/MySampleFuContainer.java then you see the error. The schema goes from
create table lingo_production.MySampleFuContainer_table (
id_AbstractContainer varchar(255) not null,
varchar(255) not null,
uuid varchar(255),
mysamplingmumble__idSuper varchar(255),
primary key (id),
unique (uuid)
);
to
create table lingo_production.MySampleFuContainer_table (
id_AbstractContainer varchar(255) not null,
id varchar(255),
mysamplingmumble_ tinyblob,
uuid varchar(255),
primary key (id_AbstractContainer),
unique (id_AbstractContainer)
);
--
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
14 years, 8 months
[Hibernate-JIRA] Created: (HCANN-8) Hibernate allow to embed non embeddable class
by Maillefer Jean-David (JIRA)
Hibernate allow to embed non embeddable class
---------------------------------------------
Key: HCANN-8
URL: http://opensource.atlassian.com/projects/hibernate/browse/HCANN-8
Project: Hibernate Commons Annotations
Issue Type: Bug
Environment: JBoss-5.1.0.GA, postgresql 8.4.0
Reporter: Maillefer Jean-David
Priority: Minor
Hibernate allows to embed (successfully !) a non embeddable class (if it was embeddable, it would throw a compiler exception)
@Entity
public class BanqueId {
@Id
int id;
}
public class Compte{
@ManyToOne
@JoinColumn(name = "compte_banqueId_id", insertable = false, updatable = false)
private BanqueId banqueId;
@Column(name = "compte_iban", length = 30)
private String iban;
}
@Entity
public class Cotisation {
@Id
int id;
@Embedded
private Compte compte;
}
In this case, using @Embeddable on Compte yields the following compiler error: "Attribute "banqueId" has invalid mapping type in this context"
Not using this annotation (as in this example) generates (at least partially) working code, but seems not to follow the specification (ejb 3.0 spec persistance, 9.1.35) !
--
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
14 years, 8 months
[Hibernate-JIRA] Created: (HHH-3278) JPA query does not work on Derby when more than one entity has a column named DATE
by Felipe Leme (JIRA)
JPA query does not work on Derby when more than one entity has a column named DATE
----------------------------------------------------------------------------------
Key: HHH-3278
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3278
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.6
Environment: Hibernate 3.2.6, Hibernate Annotations 3.3.0, Hibernate Entity Manager 3.3.1, Derby 10.4.1.3
Reporter: Felipe Leme
I have a relationship that is more like this (sorry, didn't have time to provide a simpler scenario):
- MP has a field/column called date
- MPHistory also have the same field
- there is a 1-N relationship between MP -> MPHistory
- the relationship has a @OrderBy("date") clause
When Hibernate starts using H2, everything works fine. But if I use Derby, I get the following exception:
Caused by: java.sql.SQLException: Column name 'DATE' appears more than once in the result of the query expression.
The bad SQL is the following:
Hibernate: select distinct agententit0_.id as id1_0_, mps1_.id as id0_1_, history2_.id as id3_2_, agententit0_.connected as connected1_0_, agententit0_.jmx_name as jmx4_1_0_, agententit0_.status as status1_0_, agententit0_.host_id as host10_1_0_, agententit0_.host as host1_0_, agententit0_.local as local1_0_, agententit0_.port as port1_0_, agententit0_.type as type1_0_, mps1_.date as date0_1_, mps1_.name as name0_1_, mps1_.value as value0_1_, mps1_.frequency_type as frequency5_0_1_, mps1_.is_full_mode as is6_0_1_, mps1_.is_historical as is7_0_1_, mps1_.is_normal_mode as is8_0_1_, mps1_.tolerance as tolerance0_1_, mps1_.is_summary_mode as is10_0_1_, mps1_.value_class as value11_0_1_, mps1_.info_id as info12_0_1_, mps1_.obj_id as obj13_0__, mps1_.id as id0__, history2_.date as date3_2_, history2_.value as value3_2_, history2_.value_class as value4_3_2_, history2_.mp_id as mp5_1__, history2_.id as id1__ from ggs_objects agententit0_ left outer join mps mps1_ on agententit0_.id=mps1_.obj_id left outer join mps_history history2_ on mps1_.id=history2_.mp_id where agententit0_.type in (108, 8) order by date asc
More specifically, the final 'order by date asc' should be 'order by history2_.date asc'.
Doing some debugging, I found the problem at org.hibernate.sql.Template, method isFunctionOrKeyword (line 304), which returns:
"(".equals(nextToken) ||
KEYWORDS.contains(lcToken) ||
functionRegistry.hasFunction(lcToken) ||
dialect.getKeywords().contains(lcToken) ||
FUNCTION_KEYWORDS.contains(lcToken);
The 3rd check ( dialect.getKeywords().contains(lcToken) ) returns true for Derby, then the whole method returns true, which in turns does not prepend the "$PlaceHolder$ (history2_, in this case), in the query:
else if (
isIdentifier(token, dialect) &&
!isFunctionOrKeyword(lcToken, nextToken, dialect, functionRegistry) // <<<<< THIS IS THE ISSUE >>>>
) {
result.append(TEMPLATE)
.append('.')
.append( dialect.quote(token) );
}
For now, I just removed the @OrderBy from my query (it's not really important in my case), but it looks like the Template method logic is wrong in this case.
PS: I initially open the same ticket at JBoss' site (http://jira.jboss.org/jira/browse/HIBERNATE-95) - my mistake, I guess I should have opened it here instead...
--
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
14 years, 8 months