August 2009 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-4040) Add new EntityMode.JSON

by Darren Bell (JIRA)

Add new EntityMode.JSON ----------------------- Key: HHH-4040 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4040 Project: Hibernate Core Issue Type: New Feature Affects Versions: 3.3.2 Reporter: Darren Bell We are current writing an application that is fronted by GWT and uses Searcj, Core, Validations etc. If we had JSON EntityMode this would make it seamless to integrate. We would not need to bother with Gilead (hibernate4gwt) or any other horrible methods of getting hibernate objects to/from server. Is this doable? -- 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

15 years, 4 months

1
2
0 / 0

[Hibernate-JIRA] Created: (HHH-2988) UnionSubclassEntityPersister.generateSubquery() does not use column.getQuotedName()

by benoit heinrich (JIRA)

UnionSubclassEntityPersister.generateSubquery() does not use column.getQuotedName() ----------------------------------------------------------------------------------- Key: HHH-2988 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2988 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.5 Reporter: benoit heinrich Priority: Critical Hi all, I'm new to hibernate and I'm trying to use the Inheritance strategy TABLE_PER_CLASS with a Postgres database. The postgres database contains tables and column with upper cases names (names must be quoted). In the entity I used the back-quote ` sign to quote the table names and column names. All basic requests work but when I have an association going to the virtual parent table then I got an error due to the fact that the Union subclass entity persister does not quote the column names inside the sub query. I've locate the problem and I think it occurs here: org.hibernate.persister.entity.UnionSubclassEntityPersister.java (svn rev. 11398) line 395 ------------------------------------------------------------------------------------------------ while ( citer.hasNext() ) { Column col = (Column) citer.next(); if ( !table.containsColumn(col) ) { int sqlType = col.getSqlTypeCode(mapping); buf.append( dialect.getSelectClauseNullString(sqlType) ) .append(" as "); } buf.append( col.getName() ); buf.append(", "); But should be ------------------------------------------------------------------------------------------------ buf.append( col.getQuotedName() ); Here is an example to test: Item.java: --------------------------------- @Entity @Inheritance(strategy = InheritanceType.TABLE_PER_CLASS) public abstract class Item implements java.io.Serializable { private long id; private Container parent; /** getter / setter */ @Id @Column(name = "`ID`", unique = true, nullable = false, insertable = true, updatable = true) @GeneratedValue(strategy=GenerationType.SEQUENCE, generator = "item_id_seq_generator") @SequenceGenerator(name="item_id_seq_generator", sequenceName="item_id_seq", allocationSize=1) public long getId() { return this.id; } public void setId(long id) { this.id = id; } @ManyToOne(cascade = {}, fetch = FetchType.LAZY) @JoinColumn(name = "`ParentID`", unique = false, nullable = true, insertable = true, updatable = true) public Container getParent() { return this.parent; } public void setParent(Container parent) { this.parent = parent; } } Container.java --------------------------------- @Entity @Table(name = "`CoNTaiNeR`") public class Container extends Item { private Set<Item> items = new HashSet<Item>(0); @OneToMany(cascade = { CascadeType.ALL }, fetch = FetchType.LAZY, mappedBy = "parent", targetEntity = Item.class) public Set<Item> getItems() { return this.items; } public void setItems(Set<Item> items) { this.items = items; } } SimpleItem.java --------------------------------- @Entity @Table(name = "`SimpleItem`") public class SimpleItem extends Item { /*...*/ } So when you try to get the Container.getItems() then it generates the wrong query. Cheers, /Benoit -- 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

15 years, 4 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-4103) Implement an Infinispan 2nd level cache provider

by Galder Zamarreno (JIRA)

Implement an Infinispan 2nd level cache provider ------------------------------------------------ Key: HHH-4103 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4103 Project: Hibernate Core Issue Type: New Feature Components: caching (L2) Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 3.5 Implement an Infinispan 2nd level cache provider -- 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

15 years, 4 months

1
4
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-218) add indexAll( Class type ) to rebuild indexes from all data

by Sanne Grinovero (JIRA)

add indexAll( Class type ) to rebuild indexes from all data ----------------------------------------------------------- Key: HSEARCH-218 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-218 Project: Hibernate Search Issue Type: New Feature Reporter: Sanne Grinovero Assignee: Sanne Grinovero The implementation should be as efficient as possible, to cover this scenarios: * Developers change an entity and want to test the effect on the index structure, they want do to search experiments with the new fields. * A production system is up(down)graded to a new(old) release, involving index changes. (the system is "down for maintenance" but the speed is crucial) * Existing index is corrupted/lost. (Again, speed to recover is critical) * A Database backup is restored, or data is changed by other jobs. * Some crazy developer like me prefers to disable H.Search's event listeners for some reason. (I wouldn't generally recommend it, but have met other people who have a reasonable argument to do this) * A Lucene update breaks the index format (not so irrationale as they just did on trunk). -- 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

15 years, 4 months

3
4
0 / 0

[Hibernate-JIRA] Created: (HHH-3206) criteria.uniqueResult() is null when criteria.firstResult is NOT null when projection is count

by Will Hoover (JIRA)

criteria.uniqueResult() is null when criteria.firstResult is NOT null when projection is count ---------------------------------------------------------------------------------------------- Key: HHH-3206 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3206 Project: Hibernate3 Issue Type: Bug Components: query-criteria Affects Versions: 3.2.5 Environment: JBoss 4.0/JDK 1.6/Oracle 10g Reporter: Will Hoover Priority: Minor SYNOPSIS: "criteria.uniqueResult()" is null when criteria.firstResult is NOT null when projection is count. This happens regardless if using "criteria.setProjection(Projections.countDistinct(distinctPropertyName));" or "criteria.setProjection(Projections.rowCount())". The reason why the criterias firstResult is not null is because we are reusing the same criteria to perform "criteria.list()" as "criteria.uniqueResult()" to avoid having to set all of the same restrictions etc. twice. -- 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

15 years, 4 months

3
2
0 / 0

[Hibernate-JIRA] Created: (HHH-4080) Distributed QueryCache does not evict

by andreas bester (JIRA)

Distributed QueryCache does not evict -------------------------------------- Key: HHH-4080 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4080 Project: Hibernate Core Issue Type: Bug Components: caching (L2) Affects Versions: 3.3.2, 3.3.1 Environment: Hibernate 3.3.1/2 + ehcache1.5& 1.6, multiple Tomcats Reporter: andreas bester This is essentially the exact same issue described in http://opensource.atlassian.com/projects/hibernate/browse/HHH-3734 further to this : https://forum.hibernate.org/viewtopic.php?t=979125&highlight=querycache Except It's a bug and not really an enhancement as it stops you from using Distributed QueryCache when using Invalidation. I am more than willing to test any patches. or provide more information. Details: -App1 (user facing website) -App2 (cms) 1. App1 calls: StandardQueryCache.cacheRegion.put() placing an HQL query in cache referencing table "A" 2. App2 makes an update to the entity representing table "A" 3. EHCache on App2 broadcasts an "UPDATE" message to update the UpdateTimestampsCache for table "A" 4. App1 receives the "UPDATE" message from App2 but ignores it because the UpdateTimestampsCache for App1 does not contain an entry for table "A" 5. App1 holds onto it's originally cached value and does not reflect the update that has taken place Basically, the user facing application is not receiving CMS updates for HQL queries when distributed. This is because the QueryCache API does not pass the Set of "spaces" and the StandardQueryCache does not populate the UpdateTimestampsCache with an initial entry when an HQL query is cached. -- 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

15 years, 4 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-4111) Unable to hot-swap logger configuration for Hibernate types due to local cache

by Baptiste MATHUS (JIRA)

Unable to hot-swap logger configuration for Hibernate types due to local cache ------------------------------------------------------------------------------- Key: HHH-4111 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4111 Project: Hibernate Core Issue Type: Improvement Components: core Affects Versions: 3.2.6 Environment: Hibernate 3.2.6.ga Reporter: Baptiste MATHUS Hi, Like a lot of people, I guess, we added in our app the possibility to be able to change logging (logback/log4j) configuration without having to restart the server. This works very fine, but we recently noticed that trying to activate the binding logs (via the org.hibernate.type=trace option) doesn't have any effect. After some investigation, we found out what's the cause of this problem. In NullableType, the "logger.isTraceEnabled()" value is cached in a static final boolean... So, when you start the server without any binding log and then trigger the NullableType class loading, you won't be able to see any binding log until server is restarted. It would be great if you could propose a clean solution for this use case (remove the cache?). For example, we currently are trying to debug a running production server. And we cannot see the values sent in the query we're interested in. Is the performance improvement really so significant as Gavin stated in the javadoc? Cannot we just not cache this value and trust the logging implementor for this performance aspect? As a reminder, here's the corresponding code excerpt: public abstract class NullableType extends AbstractType { /** * This is the old scheme where logging of parameter bindings and value extractions * was controlled by the trace level enablement on the 'org.hibernate.type' package... * <p/> * Originally was cached such because of performance of looking up the logger each time * in order to check the trace-enablement. Driving this via a central Log-specific class * would alleviate that performance hit, and yet still allow more "normal" logging usage/config.. */ private static final boolean IS_VALUE_TRACING_ENABLED = LogFactory.getLog( StringHelper.qualifier( Type.class.getName() ) ).isTraceEnabled(); private transient Log log; private Log log() { if ( log == null ) { log = LogFactory.getLog( getClass() ); } return log; } Thanks a lot! -- 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

15 years, 4 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HV-217) ValidatorResolutionTest#testResolutionOfMultipleSizeValidators uses generics in the constraintValidator resolution

by Emmanuel Bernard (JIRA)

ValidatorResolutionTest#testResolutionOfMultipleSizeValidators uses generics in the constraintValidator resolution ------------------------------------------------------------------------------------------------------------------ Key: HV-217 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-217 Project: Hibernate Validator Issue Type: Sub-task Reporter: Emmanuel Bernard Assignee: Hardy Ferentschik -- 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

15 years, 4 months

2
4
0 / 0

[Hibernate-JIRA] Created: (HV-218) Validator implementation resolution is based on the returned value (at runtime) instead of the returned type

by Emmanuel Bernard (JIRA)

Validator implementation resolution is based on the returned value (at runtime) instead of the returned type ------------------------------------------------------------------------------------------------------------ Key: HV-218 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-218 Project: Hibernate Validator Issue Type: Sub-task Reporter: Emmanuel Bernard Assignee: Hardy Ferentschik -- 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

15 years, 4 months

2
6
0 / 0

[Hibernate-JIRA] Created: (HHH-4109) filter and join "with" do not work

by ggsoft＠gmx.net (JIRA)

filter and join "with" do not work ---------------------------------- Key: HHH-4109 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4109 Project: Hibernate Core Issue Type: Bug Components: query-hql Affects Versions: 3.2.6 Environment: Hibernate 3.2.6GA, MySql Reporter: ggsoft(a)gmx.net Priority: Blocker When using filters and joins with a with clause, Hibernate applies the parameters in wrong order. <property name="defaultFilterCondition" value="deleted=:p_deleted"/> The filter sets only a soft delete flag. On the HQL select u, b. as buddyState from User as u left join u.buddiesForUserB as b with b.userByUserA.userid = :p_userAid where u.username = :p_username; the filter is applied to the with and to the where clause. Resulting in: ... buddiesfor1_ on user0_.userid=buddiesfor1_.userB and buddiesfor1_.deleted=0 and (buddiesfor1_.userA=0) where user0_.deleted=1 and user0_.username='myUsername' ... because the order is filter, param,filter, param But in Hibernates QueryLoader Class bindFilterParameterValues l.496 (511-516) it is assumed the filters come first. -- 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

15 years, 4 months

2
5
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues August 2009