April 2009 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-3820) Criterion should implement equals and hashCode

by Craig (JIRA)

Criterion should implement equals and hashCode ---------------------------------------------- Key: HHH-3820 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3820 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.2.6 Reporter: Craig .equals() doesn't work as expected for Criterion and its subclasses. For example: assertEquals(Restrictions.isEmpty("parents"),Restrictions.isEmpty("parents")); fails, when clearly, it should work. -- 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

12 years, 11 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HHH-2455) "Could not close a JDBC result set" output very often

by Dirk Feufel (JIRA)

"Could not close a JDBC result set" output very often ----------------------------------------------------- Key: HHH-2455 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2455 Project: Hibernate3 Type: Bug Components: core Versions: 3.2.2 Reporter: Dirk Feufel Priority: Minor If you call this type of code (like the DbTimestampType class does), the AbstractBatcher outputs a warning "Could not close a JDBC result set". The problem should be that closing the prepared statement internally also closes the associated result sets and the AbstractBatcher still has a reference to this result set. One possible solution might be to provide an additional method public void closeStatement(PreparedStatement ps, ResultSet rs); (as already present for closeQueryStatement) in the AbstractBatcher allowing to close both in the right order. PreparedStatement ps = null; try { ps = session.getBatcher().prepareStatement( timestampSelectString ); ResultSet rs = session.getBatcher().getResultSet( ps ); .... } finally { if ( ps != null ) { session.getBatcher().closeStatement( ps ); } } -- 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

12 years, 11 months

4
17
0 / 0

[Hibernate-JIRA] Created: (HHH-2907) ability to apply 'generation strategy' to generated properties

by Steve Ebersole (JIRA)

ability to apply 'generation strategy' to generated properties -------------------------------------------------------------- Key: HHH-2907 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2907 Project: Hibernate3 Issue Type: New Feature Components: core Reporter: Steve Ebersole Assignee: Steve Ebersole Priority: Minor Fix For: 3.3 Currently, the support for generated properties allows only for db-generated values (ala triggers etc). Would be great to allow the user to provide a seperate (optional) strategy for generating the generated values. It would be nice to have a generic solution, which we can build on top of for the more common use cases. Also, we may need to use a name other than 'generated' in the annotations to avoid conflicts with the current @Generated annotation; for now lets use the term @Dynamic. Consider mapping a 'created timestamp' column. Currently, provided we are using a trigger, that would look like: @Generated(INSERT) Date created; The strategy here (^^) is implicitly 'db', as the db is taking care of the generation. In the most generic form, that could be written as: @Dynamic(time=INSERT,strategy=DB) Date created; Additionally, since this is such a common case, also allow this: @CreationTimestamp Date created; The final form would also allow the definition of strategies. As an example, consider: @CreationTimestamp(strategy=NOW) Date created; Here we are not relying on the db to generate the value, but are explicitly telling Hibernate to do it (basically 'use the current timestamp to generate a value here whenever we do an insert'). -- 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

12 years, 12 months

2
8
0 / 0

[Hibernate-JIRA] Created: (HHH-3800) Allow chopping of class names in various logging scenarios

by Steve Ebersole (JIRA)

Allow chopping of class names in various logging scenarios ---------------------------------------------------------- Key: HHH-3800 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3800 Project: Hibernate Core Issue Type: Improvement Components: core Reporter: Steve Ebersole Assignee: Steve Ebersole Priority: Minor When logging enti ty class names, it would be nice to allow "collapsing" or "stripping" the entity name in various ways. Or when referencing Hibernate classes... -- 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

12 years, 12 months

1
6
0 / 0

[Hibernate-JIRA] Created: (HHH-2079) Add pre flush event listener holding all the changed entities and the operations on them

by Shay Banon (JIRA)

Add pre flush event listener holding all the changed entities and the operations on them ---------------------------------------------------------------------------------------- Key: HHH-2079 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2079 Project: Hibernate3 Type: New Feature Components: core Versions: 3.2.0.ga Reporter: Shay Banon Is there a chance to add a pre flush event listener. The event listener will have all the entities changes about to be flushed, including the operation about to be performed on them (delete, update, create). This issue relates to HHH-1725 and the collection not processed by flush exception. Maybe there would be a chance to load the lazy collections before the actual flush operation using the mentioned listener. -- 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

12 years, 12 months

4
4
0 / 0

[Hibernate-JIRA] Created: (HHH-2434) No standard way to calculate date intervals in HQL

by Don Smith (JIRA)

No standard way to calculate date intervals in HQL -------------------------------------------------- Key: HHH-2434 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2434 Project: Hibernate3 Type: Improvement Components: core Versions: 3.2.0.ga Environment: All Reporter: Don Smith Priority: Minor Date interval calculation is supported differently on different database platforms. Some allow direct arithmetic on columns, i.e. enddate - startdate. Some require functions, datediff(), timestampdiff(), etc. This causes cross-platform issues. For instance, an application I work on has to figure out the dialect that's in use (out of the four we currently support) and create the HQL string differently for each platform. This is undesirable, since we use Hibernate to enable platform neutrality; our installer asks which database the customer wants to deploy to, and sets the dialect. We'd like our codebase to be free of dialect-specific code. I propose a standard solution for this, either direct date arithmetic, or a function defintion that is ported across dialects. Timestampdiff seems to be a fairly standard function, although DB2 has different syntax than MySQL and Derby. I've seen hints that timestampdiff is part of the ANSI SQL standard, but do not have access to the documents to determine if that is the case. -- 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

12 years, 12 months

6
16
0 / 0

[Hibernate-JIRA] Created: (HHH-3348) loading context

by benjamin Leroux (JIRA)

loading context --------------- Key: HHH-3348 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3348 Project: Hibernate3 Issue Type: New Feature Affects Versions: 4.x Reporter: benjamin Leroux Priority: Minor this proposal is for creating a loading context into hibernate Let me explain: On an application, we often hesitating between the two major strategies of loading (eager or lazy). But for some reason there has no good choice. In fact, it depends on the context. So we do lazy loading and redefine some method with new request with some "join". In fact, it lead to complexity and decrease managability of the application. So my idea is to allow the definition of a context (like transactional context) where we we can put the loading strategie to adopt. with annotation it could be very easy to define such context. Let see this exemple : Avec les annotations, cela pourrait conduire à une ecriture de ce style : @LoadingStrategie (type=eager from="Car" get={"driver"}) public List<Car> getAllCarForDriving(){ // Some fonctions } @LoadingStrategie (type=eager from="Car" get={"driver","passengers"}) public List<Car> getAllCarForTravelling(){ // Some fonctions } In the method getAllCarForDriving when we call a hql request on car it automaticaly get driver but in the method getAllCarForTravelling passengers and the driver is loaded. -- 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

12 years, 12 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-3512) Registration of IdentifierGenerators (short naming)

by Steve Ebersole (JIRA)

Registration of IdentifierGenerators (short naming) --------------------------------------------------- Key: HHH-3512 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3512 Project: Hibernate Core Issue Type: New Feature Components: core, metamodel Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 3.4, 4.x Another way to look at this is to allow configuration of IdentifierGeneratorFactory. Either allow explicit registration under a short name in config: <identifier-generator name="sequence-style" class="org.hibernate.id.enhanced.SequenceStyleGenerator"/> or via an explicit contract: public interface Registerable { public String getRegistrationName(); } public class SequenceStyleGenerator implements IdentifierGenerator, Registerable { ... public String getRegistrationName() { return "sequence-style"; } } The second, while certainly more verbose, can be used applied to other situations where we want to allow registration moving forward (types, property-accessor, etc). -- 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

12 years, 12 months

2
8
0 / 0

[Hibernate-JIRA] Created: (HHH-2764) EntityType.deepCopy needs to copy for EntityType.DOM4J

by Alan Krueger (JIRA)

EntityType.deepCopy needs to copy for EntityType.DOM4J ------------------------------------------------------ Key: HHH-2764 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2764 Project: Hibernate3 Issue Type: Bug Affects Versions: 3.2.2 Environment: Hibernate 3.2.2 Reporter: Alan Krueger Using DOM4J with a set of composite-elements that contains a many-to-one. When loading this from the database, the many-to-one piece of the composite-element is disappearing from the XML. I can see the collection being built and the properties on the elements of the collection being set, but the many-to-one property disappears after that. Investigating this, it looks like when PersistentElementHolder.getSnapshot is called and a deepCopy is performed, the EntityType.deepCopy method returns the value to be copied rather than copying it. This interacts poorly with the DOM4J tree, since each Element can only have a single Element parent. When the properties are set on this, a detach is performed that yanks the original element out of its parent. -- 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

12 years, 12 months

3
4
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-349) Allow custom Loader in FullTextQueryImpl

by Julien Kronegg (JIRA)

Allow custom Loader in FullTextQueryImpl ---------------------------------------- Key: HSEARCH-349 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-349 Project: Hibernate Search Issue Type: New Feature Components: query Affects Versions: 3.1.0.GA Environment: Hibernate 3.3.1.GA, DB2 Reporter: Julien Kronegg Priority: Minor When doing an native SQL query containing join and other complicated stuff, one can get a List<MyObject> using the following code: List<MyObject> list = entityManager.createNativeQuery("SELECT ...", MyObject.class).getResultList(); The MyObject class is an JPA Entity, but is not connected to a database table: the MyObject instance is reconstructed automatically by mapping the ResultSet column names and the MyObject field names. This object list can be indexed using Hibernate Search (by adding @Indexed and @Field annotations to the MyObject entity). When doing an Hibernate Search query, the FullTextQueryImpl.list() method uses a Loader which try to load the MyObject entities from the database by a query such as "SELECT ... FROM MYOBJECT where id in (?,?,?,..)" (where the list of "?" is the list of identifiers returned by Lucene). Here, we have a problem: the MYOBJECT table does not exist and obviously an exception is raised. The desired result would be for example to look into the initial List<MyObject> "list" instead of asking to the database. This functionnality could be done very simply by adding a "Loader customLoader" field (with its public getter/setter) in the org.hibernate.search.query.FullTextQueryImpl class and by modifying the getLoader() method such as: private Loader getLoader(Session session, SessionFactoryImplementor sessionFactoryImplementor) { if (customLoader!=null) { customLoader.init(session, sessionFactoryImplementor); return customLoader; } ... } After this modification, the programmer can design its own Loader which implements whatever loading strategy. For the example above, the Loader.load(EntityInfo[]) method may looks for each EntityInfo.id in the initially obtained List<MyObject> "list". There is a workaround: copy the full source code of FullTextQueryImpl and add the described modifications. -- 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

13 years

3
8
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues April 2009