[Hibernate-JIRA] Created: (ANN-863) (AnnotationBinder) Make alphabetically sort of declared properties optional.
by Jan Ritzenhoff (JIRA)
(AnnotationBinder) Make alphabetically sort of declared properties optional.
----------------------------------------------------------------------------
Key: ANN-863
URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-863
Project: Hibernate Annotations
Issue Type: Improvement
Components: binder
Affects Versions: 3.4.0.GA
Reporter: Jan Ritzenhoff
In Line 1025 of org.hibernate.cfg.AnnotationBinder the declared properties are alphabetically sorted by default. As a result the columns of the CREATE TABLE statement are also alphabetically sorted even if the class dictates another order.
Example:
@Entity
public class MyClass {
@Id
public long id;
public String b;
public String a;
...getter-setter....
}
results in a table like:
| id | a | b
but I (or an important customer, resp.) would like to have an order as declared in the class (for better manual readability):
| id | b | a
Sometimes it is important to have this order - eg if you look on big tables with db-tools and you want to see the most important columns first. (and often scientists do so)
My wish is to implement a property like:
<property name="hibernate.sortDeclaredFields" value="true" />
So the columns 1025 - 129 become optional!
// Collections.sort( properties, new Comparator<XProperty>() {
// public int compare(XProperty property1, XProperty property2) {
// return property1.getName().compareTo( property2.getName() );
// }
// } );
--
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
[Hibernate-JIRA] Created: (HBX-1141) IndexOutOfBoundsException in DocExporter.generatePackageSummary when there is no package
by Julien Kronegg (JIRA)
IndexOutOfBoundsException in DocExporter.generatePackageSummary when there is no package
----------------------------------------------------------------------------------------
Key: HBX-1141
URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-1141
Project: Hibernate Tools
Issue Type: Bug
Components: hbm2doc
Affects Versions: 3.2.4 Beta1
Environment: http://anonsvn.jboss.org/repos/hibernate/branches/Branch_3_2/HibernateExt...
Reporter: Julien Kronegg
Attachments: patch.txt
When generating the documentation with the Ant task <hbm2doc>, the org.hibernate.tool.hbm2x.DocExporter.generatePackageSummary() method raises a java.lang.IndexOutOfBoundsException if there is no package. This can occur if the reveng.xml parameters results in having no entity. For example:
<table-filter match-name="dummy_table_name_not_existing_in_db" package="foo.bar"/>
The stack trace is:
java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at java.util.ArrayList.remove(ArrayList.java:538)
at org.hibernate.tool.hbm2x.DocExporter.generatePackageSummary(DocExporter.java:386)
...
This is the corresponding code snippet:
384 List list = docHelper.getPackages();
385 //Remove All Classes
386 list.remove(0);
...
451 List list = docHelper.getPackages();
452 //Remove All Classes
453 list.remove(0);
...
505 List packageList = docHelper.getPackages();
506 packageList.remove(0);
This code makes the assumption that at least one package is present, which is not the case. Lines 386, 453 and 506 should be replaced by:
if (list.size()>0) list.remove(0); // for line 506, packageList instead of list
The patch implements these changes.
--
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
[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
[Hibernate-JIRA] Commented: (HHH-1395) Hierarchical entity data management using 'modified preorder tree traversal algorithm' (nested set trees)
by Cameron McEwing (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1395?page=c... ]
Cameron McEwing commented on HHH-1395:
--------------------------------------
Hi There, I have been watching this for a while now, any chance this will be integrated into Hibernate in the near future? I would be keen to use this, especially if it allowed moving of whole sub-trees from one parent to another. Cheers Cameron
> Hierarchical entity data management using 'modified preorder tree traversal algorithm' (nested set trees)
> ----------------------------------------------------------------------------------------------------------
>
> Key: HHH-1395
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1395
> Project: Hibernate Core
> Issue Type: New Feature
> Components: core, query-hql
> Environment: Hibernate 3.1 plus Annotations extending EJB3 implementation
> Reporter: James Salt
> Attachments: nestedset.tar.gz
>
> Original Estimate: 3 weeks
> Remaining Estimate: 3 weeks
>
> An enhancement to allow entities to exist in a managed tree (DAG) structure, via the use of property annotations and entity annotations. With an extension to the HQL language to mimic the Oracle recusive query clause.
> This would be classically be useful for Bill of Material uses, or any tree like entity structure.
> I have implemented a homebrew approach using the 'adjacency list method' , and a post persist call back method to set the node path. Although I think a more full blown optimised algorithm would be the 'modified preorder tree traversal algorithm'.
> In the annotations world this could be implemented using an annotation like @Hierarchical to the entity, with a @Parent (mask for @ManyToOne) annotation on the parent field/parameter and @Children (mask for @OneToMany) annotation on the list of children entities.
> Then a postupdate method could be implemented for the entity type, that recalculates the tree meta data -i.e. parent, left and right.
> I believe this would be a valuable extension (useful for many common data models) to the hibernate core product that could be exposed through annotations as I have discussed and the hbm.xml.
> The users of such a system would be aware of the performance implications on insert/update/delete, but gain a massive performance gain on querying a tree data model.
>
--
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