October 2009 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HSEARCH-367) Support only one kind of Similarity per index

by Sanne Grinovero (JIRA)

Support only one kind of Similarity per index --------------------------------------------- Key: HSEARCH-367 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-367 Project: Hibernate Search Issue Type: Bug Reporter: Sanne Grinovero Fix For: 3.2.0 pasted from the developer's list: Each time a new Document is added to the index, the similarity relevant to that entity is looked up from the pertaining documentBuilder and set to the indexwriter: AddWorkDelegate: Similarity similarity = documentBuilder.getSimilarity(); writer.setSimilarity( similarity ); writer.addDocument( work.getDocument(), analyzer ); So the analyzer is scoped per document, the similarity is globally set on the indexwriter. Does this make sense to update the similarity for each add operation type? This is a problem as I can't use two (more) threads to add documents to the same index. Is there a good use case for which someone might need a different Similarity implementation for different entities contained in the same index? I'd like to change that to an "illegal configuration". -- 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, 2 months

1
2
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-394) @ProvidedId gets ignored

by Hardy Ferentschik (JIRA)

@ProvidedId gets ignored ------------------------ Key: HSEARCH-394 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-394 Project: Hibernate Search Issue Type: Bug Components: engine Affects Versions: 3.1.1.GA Reporter: Hardy Ferentschik Assignee: Hardy Ferentschik Fix For: 3.2.0 The check for the @ProvidedId has to be moved into the init() method of DocumentBuilderIndexedEntity -- 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, 2 months

1
2
0 / 0

[Hibernate-JIRA] Created: (ANN-752) Setup continous integration

by Hardy Ferentschik (JIRA)

Setup continous integration --------------------------- Key: ANN-752 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-752 Project: Hibernate Annotations Issue Type: Task Reporter: Hardy Ferentschik Assignee: Hardy Ferentschik Priority: Minor Hibernate Annotations should be build continuously via Hudson. If possible each build should run the tests against multiple databases. -- 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, 2 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HHH-4528) Read mapping annotations from entity properties rather than the composite pk

by Emmanuel Bernard (JIRA)

Read mapping annotations from entity properties rather than the composite pk ---------------------------------------------------------------------------- Key: HHH-4528 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4528 Project: Hibernate Core Issue Type: Sub-task Components: annotations Affects Versions: 3.5.0.Beta-1 Reporter: Emmanuel Bernard Assignee: Hardy Ferentschik Fix For: 3.5 Attachments: AnnotationBinder.java.diff Hardy, can you check this patch from Stale and add tests. Stale is working on Mafia-style useless SpecJ and the commitee is making it hard for us to pass the tests. Emmanuel -- 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, 2 months

3
3
0 / 0

[Hibernate-JIRA] Created: (ANN-753) Allow running tests against different databases by using a simple switch

by Hardy Ferentschik (JIRA)

Allow running tests against different databases by using a simple switch ------------------------------------------------------------------------ Key: ANN-753 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-753 Project: Hibernate Annotations Issue Type: Task Reporter: Hardy Ferentschik Assignee: Hardy Ferentschik Priority: Minor Currently you have to edit hibernate.properties to be able to run the tests against a different database. The settings of this file should be externalized and filters should be used to filter appropriate settings according to a property, eg 'ant clean junit -Dtargetdb=mysql'. To make this really useful one would also need a way within the test to skip it for a particular database. Some tests don't make sense against a certain target db. This might be a separate issue. Maybe one could switch to Junit 4 and add some custom annotation for enabling/disabling a test depending on the db. -- 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, 2 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HHH-4530) Change the docbook style for Annotations and EntityManager to the latest styles used in the other Core modules

by Hardy Ferentschik (JIRA)

Change the docbook style for Annotations and EntityManager to the latest styles used in the other Core modules -------------------------------------------------------------------------------------------------------------- Key: HHH-4530 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4530 Project: Hibernate Core Issue Type: Task Components: annotations, documentation, entity-manager Affects Versions: 3.5.0.Beta-1 Reporter: Hardy Ferentschik Assignee: Hardy Ferentschik Fix For: 3.5 -- 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, 2 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HV-257) ReflectionHelper.getValue fails to retrieve values from methods defined on a parent interface

by Amir Kibbar (JIRA)

ReflectionHelper.getValue fails to retrieve values from methods defined on a parent interface --------------------------------------------------------------------------------------------- Key: HV-257 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-257 Project: Hibernate Validator Issue Type: Bug Components: validators Affects Versions: 4.0.0.GA, 4.0.0.CR1, 4.0.0.Beta3, 4.0.0.Beta2, 4.0.0.Beta1, 4.0.0.Alpha3, 4.0.0.Alpha2, 4.0.0.Alpha1, 3.1.0.GA, 3.1.0.CR2, 3.1.0.CR1, 3.0.0.ga, Bundle 3.2.1 Environment: hibernate-validator 4.0.0.CR1 Reporter: Amir Kibbar I've defined an interface A with method foo with a constraint annotation on it. I've then defined an interface B that extends interface A. I've created a proxy (invocation handler) that implements interface B at runtime. When I try to validate the proxy object I get an IllegalAccessException because the modifier on the method the ReflectionHelper.getValue() is trying to invoke has the "public abstract" modifiers. This can easily be solved if the getValue() will set method.setAccesible(true) before attempting to invoke it (and then reset it to the previous value obviously). thanks, Amir -- 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, 2 months

2
6
0 / 0

[Hibernate-JIRA] Created: (HHH-4518) Undeterministic behavior on Session.close without commit or rollback

by Vladimir Nicolici (JIRA)

Undeterministic behavior on Session.close without commit or rollback -------------------------------------------------------------------- Key: HHH-4518 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4518 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.3.0.SP1 Environment: Hibernate 3.3.0.SP1, Oracle 10.2.0.1.0, c3p0 pool Reporter: Vladimir Nicolici Attachments: Test.java Closing a session without rollback or commit may cause the uncommitted changes to be committed. First scenario: Step 1. Obtain a session using SessionFactory.openSession, begin a transaction, makes some changes, don't commit, don't rollback, close the session. Step 2. Obtain a new session, begin a transaction, do some unrelated changes, commit the transaction, close the session. Result: the uncommitted changes performed in the first transaction are committed when the second transaction is committed. This shouldn't happen, what happens with the second session should not affect the changes performed with the first session. However, if instead of committing, you rollback the transaction from step 2, it also rollbacks the changes from step 1. Even worse, the second session has access to the uncommitted data generated by the first transaction, violating transaction isolation. Second scenario: 0. Configure a SessionFactory for an Oracle Database, with the c3p0 pool. 1. Obtain a session using SessionFactory.openSession, begin a transaction, makes some changes, don't commit, don't rollback, close the session. 2. Close the SessionFactory. Result: the uncommitted changes performed in the first transaction are committed when the SessionFactory is closed, because all the connections in the pool are closed, and oracle connections perform an implicit commit on close. If you use a different database, the changes will be rolled back. To conclude the behavior when a session doesn't commit or rollback depends on: - what the next Session does with the Connection; - what database you are using. What makes it worse is that the idiom recommended in the documentation for a non-managed environments (http://docs.jboss.org/hibernate/stable/core/reference/en/html/transaction...) is not safe: // Non-managed environment idiom Session sess = factory.openSession(); Transaction tx = null; try { tx = sess.beginTransaction(); // do some work ... tx.commit(); } catch (RuntimeException e) { if (tx != null) tx.rollback(); throw e; // or display error message } finally { sess.close(); } If "do some work" will throw java.lang.Error, it will not be caught by the catch clause for RuntimeException, the compiler will not complain that the Error is not caught, because a java.lang.Error behaves the same as RuntimeException, not requiring the programmer to catch it. This way, both the commit and the rollback code will not be executed, which may cause the first or second scenario to occur. What developers using hibernate may do until the issue is fixed: - replace "catch (RuntimeException e)" with "catch (Throwable t)" this will catch both java.lang.RuntimeException and java.lang.Error This may not be a good idea though, because according to the java.lang.Error JavaDoc (http://java.sun.com/javase/6/docs/api/java/lang/Error.html): "a reasonable application should not try to catch" it. - a better solution might be to move the rollback code to the "finally" block, like this: // Non-managed environment idiom Session sess = factory.openSession(); Transaction tx = null; try { tx = sess.beginTransaction(); // do some work ... tx.commit(); } finally { if (tx != null && !tx.wasCommitted()) tx.rollback(); sess.close(); } What I feel the developers of Hibernate should do: - update the documentation to document the issue - modify Session.close to perform rollback if the transaction has not been explicitly committed or rollback. If for some reason this can't be the default behavior, at least provide a configuration parameter to activate such behavior. This will result in much simpler and safer code, that will look like this: // Non-managed environment idiom Session sess = factory.openSession(); try { sess.beginTransaction(); // do some work ... sess.getTransaction().commit(); } finally { sess.close(); } Which reminds me that it would be also be nice if Session would have a commitTransaction method... I attached example code that reproduces the problem. -- 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, 2 months

2
4
0 / 0

[Hibernate-JIRA] Updated: (HHH-1907) offload metadata information from ComponentType to SessionFactory

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1907?page=c... ] Steve Ebersole updated HHH-1907: -------------------------------- Fix Version/s: (was: 3.5) cfg-rework > offload metadata information from ComponentType to SessionFactory > ----------------------------------------------------------------- > > Key: HHH-1907 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1907 > Project: Hibernate Core > Issue Type: Improvement > Components: core > Reporter: Steve Ebersole > Assignee: Steve Ebersole > Fix For: cfg-rework > > > Specifically, we need to move all the code directly dealing with property-access, instantiation, etc out of here. So where do we move it? Well, EntityType for example moves this stuff off to the persisters; the type then just looks up the persister when needed. Not sure we actually need a persister per-se for handling components; perhaps just ComponentMetamodel is enough... > Why is this important? Well the way ComponentType is currently structured leads to the need for certain configuration properties to be classloader scoped (static on Environment) instead of SessionFactory scoped. This is painful for two in particular: 1) whether to use reflection optimization and 2) bytecode provider. > Also, this change should allow us to cleanup how property accessors are built -- 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, 2 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-2412) Hibernate 3 cannot be compiled under JDK 6

by Ahmet A. Akin (JIRA)

Hibernate 3 cannot be compiled under JDK 6 ------------------------------------------ Key: HHH-2412 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2412 Project: Hibernate3 Type: Task Components: core Versions: 3.2.1, 3.2.2 Environment: windows xp, JDK 6 Reporter: Ahmet A. Akin Hibernate code cannot be compiled under JDK 6. Problems and possible solutions: 1- org.hibernate.jdbc.ResultSetWrapper implements ResultSet. But in Java 6, there are big changes in Resultset interface, and maybe 20+ more methods needs to be implemented in the ResultSetWrapper class. i would suggest eliminating this wrapper class once and for all, because it is only used in one method (in ColumnNameCache, getIndexForColumnName method) and i dont think there is a justification for using that wrapper class. 2- org.hibernate.lob.SerializableBlob needs to implement new Blob interface methods: public void free() throws SQLException; public InputStream getBinaryStream(long pos, long length) throws SQLException But, if this class is publicly accesible or used by API's back compatibility issues needs to be checked. 3- Same as number 2, org.hibernate.lob.BlobImpl class needs to implement new Blob methods. 4- org.hibernate.lob.SerializableClob class needs to implent new Clob methods. 5- org.hibernate.lob.ClobImpl , same as 4. In fact, Java 6 has a lot of JDBC improvements, maybe a java6 special extra package can be created., but that is a whole different issue. -- 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, 2 months

8
18
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues October 2009