November 2008 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HBX-978) unique=true attribute of primary key in generated class prevents the schema to be regenerated

by Ali Sadik Kumlali (JIRA)

unique=true attribute of primary key in generated class prevents the schema to be regenerated --------------------------------------------------------------------------------------------- Key: HBX-978 URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-978 Project: Hibernate Tools Issue Type: Bug Environment: OS: Windows Vista 6.0,x86 Database: Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production Java VM: Java HotSpot(TM) Server VM 1.5.0_11-b03,Sun Microsystems Inc. Eclipse Europa: Version: 3.3.0 Build id: I20070621-1340 HibernateTools-3.2.0.beta10 Reporter: Ali Sadik Kumlali Priority: Minor Hi, When I reverse engineer against Oracle, unique=true attribute is added to @Column annotation of primary key column. But, when I generate schema from these generated files, Oracle throws "ORA-02261: such unique or primary key already exists in the table" error. I first ran into this situation while trying Seam and posted the problem to Seam's forum: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=116478. After I got the response, decided to try it without Seam. Then, downloaded the latest HibernateTools & Eclipse Europa and reverse engineered the schema. I saw that generated classes have unique=true attribute which clearly showed that the problem was related with HibernateTools, not with Seam. Here is the DDL of the table against which I made my test: CREATE TABLE PEOPLE ("ID" NUMBER NOT NULL, "SURNAME" VARCHAR2(50 BYTE), "NAME" VARCHAR2(25 BYTE), CONSTRAINT "PEOPLE_PK" PRIMARY KEY ("ID")); Regards, Ali Sadik Kumlali -- 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

11 years, 7 months

8
11
0 / 0

[Hibernate-JIRA] Created: (HHH-3135) SQL Server Dialect maps BIGINT to NUMERIC(19,0)

by Dominik Enkelmann (JIRA)

SQL Server Dialect maps BIGINT to NUMERIC(19,0) ----------------------------------------------- Key: HHH-3135 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3135 Project: Hibernate3 Issue Type: Bug Affects Versions: 3.2.5 Environment: MS SQL Server Reporter: Dominik Enkelmann Priority: Trivial The SQLServerDialect.java maps the Hibernate BIGINT type to a NUMERIC(19,0) colum. The result is, that all Long fields in persisten classes map to hibernate-bigints which generate numeric(19,0) database column. Longs are typically used for surrogate primary keys and should be implemented as native SQL BIGINTs where possible. SQL Server supports SQL BIGINT since version 2000. There is a similar issue with the SQL BIT type that should be implemented as a native BIT column in SQL Server. A possible solution could be a pre-.SQL Server 2000 dialect and an updated SQL Server dialect. I filed a more detailed description with workaround in the user forum http://forum.hibernate.org/viewtopic.php?p=2377674#2377674 -- 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

11 years, 7 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-2942) Improve support for PostgreSQL

by Diego Pires Plentz (JIRA)

Improve support for PostgreSQL ------------------------------ Key: HHH-2942 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2942 Project: Hibernate3 Issue Type: Improvement Components: metamodel Reporter: Diego Pires Plentz Assignee: Diego Pires Plentz Priority: Minor Improve support for features in PostgreSQL 7.x and 8.x. I will probably create a new one for 8.x series. I asked for help of postgresql hackers. http://archives.postgresql.org/pgsql-hackers/2007-11/threads.php#00462 Docs index: http://www.postgresql.org/docs/ -- 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

11 years, 7 months

4
5
0 / 0

[Hibernate-JIRA] Created: (HBX-935) H2MetaDataDialect for identity detection

by Max Rydahl Andersen (JIRA)

H2MetaDataDialect for identity detection ---------------------------------------- Key: HBX-935 URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-935 Project: Hibernate Tools Issue Type: Sub-task Components: reverse-engineer Affects Versions: 3.2beta9 Reporter: Max Rydahl Andersen Fix For: 3.2beta10 -- 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

11 years, 7 months

4
15
0 / 0

[Hibernate-JIRA] Created: (HHH-2770) Action observers for event listeners

by Christian Bauer (JIRA)

Action observers for event listeners ------------------------------------ Key: HHH-2770 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2770 Project: Hibernate3 Issue Type: New Feature Components: core Reporter: Christian Bauer Priority: Minor Talked to Steve about a feature he calls "action observers", which would allow the following use case: - Write a FlushEventListener - Observer for what has been deleted, inserted, updated (action queues) This removes some of the pain that comes from missing communication between listeners. For example, you can easily move code you would traditionally write in an Interceptor into a FlushEventListener if you only need inserted/deleted/udpated records. -- 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

11 years, 8 months

3
6
0 / 0

[Hibernate-JIRA] Created: (HHH-3452) Statistics for Criteria Queries

by Rohit N (JIRA)

Statistics for Criteria Queries ------------------------------- Key: HHH-3452 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3452 Project: Hibernate3 Issue Type: New Feature Components: query-criteria Reporter: Rohit N Priority: Blocker Criteria Queries are not part of the Query Statistics. This gives an incomplete "picture" to the user. Currently, the Statistics is only for HQL queries. -- 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

11 years, 8 months

9
16
0 / 0

[Hibernate-JIRA] Created: (ANN-630) @ManyToMany and @Index

by Peter K. Guldbæk (JIRA)

@ManyToMany and @Index ---------------------- Key: ANN-630 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-630 Project: Hibernate Annotations Issue Type: Bug Affects Versions: 3.3.0.ga Environment: Windows Vista java version "1.5.0_11" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03) Java HotSpot(TM) Client VM (build 1.5.0_11-b03, mixed mode) Reporter: Peter K. Guldbæk I have trouble adding an index to a column of a table which is part of a many-to-many property mapping. The following example causes a NullPointerException when generating the DDL (the exception can be seen at the end of my post): @Entity @Table(name="usr") public class User implements Serializable { @Id @GeneratedValue(strategy=GenerationType.AUTO) public Integer id; @ManyToMany(targetEntity=Target.class, cascade={}) @Index(name="fkey_usr_target", columnNames="usr_id") @JoinTable(name="usr_target", joinColumns=@JoinColumn(name="usr_id"), inverseJoinColumns=@JoinColumn(name="target_id")) public Collection<Target> targets; } @Entity @Table(name="target") public class Target implements Serializable { @Id @GeneratedValue(strategy=GenerationType.AUTO) public Integer id; @Basic public String myValue; } NullPointerException thrown when an @Index annotation is used with a @ManyToMany: java.lang.NullPointerException at org.hibernate.cfg.AnnotationBinder.processElementAnnotations(AnnotationBinder.java:1594) at org.hibernate.cfg.AnnotationBinder.bindClass(AnnotationBinder.java:733) at org.hibernate.cfg.AnnotationConfiguration.processArtifactsOfType(AnnotationConfiguration.java:498) at org.hibernate.cfg.AnnotationConfiguration.secondPassCompile(AnnotationConfiguration.java:277) at org.hibernate.cfg.Configuration.buildMappings(Configuration.java:1115) at org.hibernate.tool.ant.ConfigurationTask.getConfiguration(ConfigurationTask.java:56) at org.hibernate.tool.ant.HibernateToolTask.getConfiguration(HibernateToolTask.java:299) at org.hibernate.tool.ant.Hbm2DDLExporterTask.execute(Hbm2DDLExporterTask.java:45) at org.hibernate.tool.ant.HibernateToolTask.execute(HibernateToolTask.java:183) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288) at sun.reflect.GeneratedMethodAccessor19.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:105) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:357) at org.apache.tools.ant.Target.performTasks(Target.java:385) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1329) at org.apache.tools.ant.Project.executeTarget(Project.java:1298) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) at org.apache.tools.ant.Project.executeTargets(Project.java:1181) at org.apache.tools.ant.Main.runBuild(Main.java:698) at org.apache.tools.ant.Main.startAnt(Main.java:199) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104) -- 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

11 years, 8 months

8
10
0 / 0

[Hibernate-JIRA] Created: (HHH-2318) Sometimes wrong classloader used for proxy interfaces

by Jan Wiemer (JIRA)

Sometimes wrong classloader used for proxy interfaces ----------------------------------------------------- Key: HHH-2318 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2318 Project: Hibernate3 Type: Bug Components: core Versions: 3.2.1 Reporter: Jan Wiemer For some of our business classes we used a Mapping declaring the class to be lazy initialized and providing a proxy interface like e.g.: <class name="TestClassImpl" proxy="TestClass" table="testTable" lazy="true"> ... </class> Using classes mapped this way - e.g. as endpoint of a one to one relation - sporadically leads to exceptions like the following: org.hibernate.PropertyAccessException: IllegalArgumentException occurred while calling setter of test.AbstractTestClass2Impl.testField at org.hibernate.property.BasicPropertyAccessor$BasicSetter.set(BasicPropertyAccessor.java:104) at org.hibernate.tuple.entity.AbstractEntityTuplizer.setPropertyValues(AbstractEntityTuplizer.java:337) at org.hibernate.tuple.entity.PojoEntityTuplizer.setPropertyValues(PojoEntityTuplizer.java:200) at org.hibernate.persister.entity.AbstractEntityPersister.setPropertyValues(AbstractEntityPersister.java:3514) at org.hibernate.engine.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:129) at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:842) at org.hibernate.loader.Loader.doQuery(Loader.java:717) at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:224) at org.hibernate.loader.Loader.doList(Loader.java:2211) at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2095) at org.hibernate.loader.Loader.list(Loader.java:2090) at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:388) at org.hibernate.hql.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:338) at org.hibernate.engine.query.HQLQueryPlan.performList(HQLQueryPlan.java:172) at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1121) at org.hibernate.impl.QueryImpl.list(QueryImpl.java:79) at org.hibernate.impl.AbstractQueryImpl.uniqueResult(AbstractQueryImpl.java:804) Note that the application is residing in a different classloader than hibernate (and CGLIB...). Examining the situation we see that the value passed to the setter was a CGLIB proxy. Internally the proxy stores an array of interfaces the proxy should implement. In our situation this interface contains the HibernateProxy interface and our business interface provided as proxy interface in the mapping. In this interface array we checked the classloader of the interfaces. As expected the HibernateProxy interface is loaded by the system classloader and our interface was loaded by our custom classloader. However examining the actual interfaces of the proxy (with proxy.getClass().getInterfaces()[i].getClassLoader() for all i) shows that all interfaces are loaded with the system classloader. This causes the exception above. Doing some more experiments we experience that the problem does not occur all the time. Sometimes the actual proxy interfaces are as expected (the HibernateProxy interface is loaded by the system classloader and our interface was loaded by our custom classloader). We notice that each time the test failed the HibernateProxy was the first interface in the interface array stored in the proxy. Some experiments with the CGLIB (the Enhancer class) shows us that (if there is no superclass given) they use the classloader of the first passed interface as default classloader (compare method net.sf.cglib.proxy.Enhancer.getDefaultClassLoader()). Finally we find out that hibernate passes the proxy interfaces in an arbitrary order since they are using a HashSet for the proxy interfaces in the method org.hibernate.tuple.entity.PojoEntityTuplizer.buildProxyFactory(PersistentClass persistentClass, Getter idGetter, Setter idSetter). This Hash set is passed to the method org.hibernate.proxy.pojo.cglib.CGLIB_ProxyFactory.postInstantiate(...). There it is simply converted to an Array (leading to a randomized order). As a workaround it is possible to patch the class org.hibernate.proxy.pojo.cglib.CGLIB_ProxyFactory and add reorganize the array if the HibernateProxy interface is the first one: this.interfaces = (Class[]) interfaces.toArray(NO_CLASSES); //----->PATCH<-------- if(this.interfaces.length > 1) { Class firstIfc = this.interfaces[0]; if(firstIfc.getName().startsWith("org.hibernate")) { this.interfaces[0] = this.interfaces[1]; this.interfaces[1] = firstIfc; System.err.println("Replace: " + firstIfc.getName() + " by " + this.interfaces[0].getName()); } } //-------------------- After applying this patch everything woks as expected. Compare with the discussion in: http://forum.hibernate.org/viewtopic.php?p=2334617#2334617 -- 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

11 years, 8 months

4
11
0 / 0

[Hibernate-JIRA] Created: (HHH-3603) Hibernate custome classloader

by Behrang Javaherian (JIRA)

Hibernate custome classloader ----------------------------- Key: HHH-3603 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3603 Project: Hibernate Core Issue Type: New Feature Affects Versions: 3.3.0.GA Reporter: Behrang Javaherian We are trying to use hibernate in a OSGi like kind of environment. We have a code module that creates the session factory. We want to be able to add classes to session factory and recreated the session factory as needed. But hibernate is always using the current class loader which cause class cast exception if we try to add model classes from child bundles (which has their own class loader). To overcome this issue we had to patch the hibernate internal ReflectHelper and change the classForNameMethod to this: return PlugableClassFinder.getInstance().classForName(name); and here is the code for PlugableClassFinder class: public class PlugableClassFinder { private Set<ClassLoader> classLoaders = new HashSet<ClassLoader>(); public Class classForName(String name) throws ClassNotFoundException { try { ClassLoader contextClassLoader = Thread.currentThread().getContextClassLoader(); if ( contextClassLoader != null ) { return contextClassLoader.loadClass(name); } } catch ( Throwable t ) { } try { return Class.forName(name); } catch (ClassNotFoundException e) { } //now look into the registerred class loaders for (ClassLoader classLoader : classLoaders) { try { return classLoader.loadClass(name); } catch (ClassNotFoundException e) { } } throw new ClassNotFoundException("Cannot find class: " + name); } public void registerClassLoader(ClassLoader classLoader) { classLoaders.add(classLoader); } public void deregisterClassLoader(ClassLoader classLoader) { classLoaders.remove(classLoader); } private static final PlugableClassFinder instance = new PlugableClassFinder(); public static PlugableClassFinder getInstance() { return instance; } } Now every bundle will register its class loader with PlugableClassFinder class. Maybe hibernate should either allow plugging new class loaders to resolve classes or provide a hook o an interface that we can implement to replace the internal class resolving mechanism. For the moment our approach if working for us. Regards Behrang Javaherian http://www.beyondng.com -- 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

11 years, 8 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-3201) Provide osgi informations in hibernate MANIFEST.MF to be recognized as osgi-bundle

by Baptiste MATHUS (JIRA)

Provide osgi informations in hibernate MANIFEST.MF to be recognized as osgi-bundle ---------------------------------------------------------------------------------- Key: HHH-3201 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3201 Project: Hibernate3 Issue Type: Improvement Components: core Affects Versions: 3.2.5 Reporter: Baptiste MATHUS Hi all, It would be great if the packaging of Hibernate could be done as osgi compatible jar. With little configuration, some plugins already exist to do it in simply. For informaiton, a jar can become osgi-compatible only by adding some properties inside the META-INF/MANIFEST.MF file. It lets the jar totally usable in a non-osgi environment, but let the jar be recognized as a "bundle" in an osgi-container (Eclipse, Apache Felix...). A good entrypoint for this, using maven2 to package, could be http://felix.apache.org/site/maven-bundle-plugin-bnd.html#MavenBundlePlug.... For example, Spring already did and their available jars on repo1.maven.org can be put directly in a eclipse/plugins directory and be recognized as a bundle/plugin. Cheers. -- 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

11 years, 8 months

4
6
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues November 2008