[Hibernate-JIRA] Created: (HBX-1018) hbm2java does not generate unique sequence generator names
by Nikolai Gagov (JIRA)
hbm2java does not generate unique sequence generator names
----------------------------------------------------------
Key: HBX-1018
URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-1018
Project: Hibernate Tools
Issue Type: Bug
Components: hbm2java
Affects Versions: 3.2.cr1
Environment: Hibernate 3.2.5.ga, Oracle 10g
Reporter: Nikolai Gagov
Priority: Minor
Attachments: reveng.zip
We use hbm2java to create EJB3 from database. hbm2java generates @SequenceGenerator(name="generator", ...) @GeneratedValue(strategy=SEQUENCE, generator="generator") for all primary keys. Some persistence providers like Toplink reports this as error during validation. It could be good if hbm2java generates unique SequenceGenerator names.
For this issue I propose to implement simillar behaviour as the one for generated sequence name. In org.hibernate.tool.hbm2x.pojo.EntityPOJOClass.generateAnnIdGenerator() we could retreive the SequenceGenerator name from properties. These properties could be populated inside some predefined from user ReverseEngineeringStrategy. In it's method getTableIdentifierProperties(TableIdentifier) we could set in properties what ever we want.
--
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
18 years, 4 months
[Hibernate-JIRA] Updated: (HHH-1476) Table.qualify does not handle dialect diferences
by Mike A. Meyer (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1476?page=c... ]
Mike A. Meyer updated HHH-1476:
-------------------------------
Attachment: informix-table-qname-patch-NPAC-vs-v324sp1.diff
This patch works for v3.2.4sp1 (currently used with JBoss 4.2.1+)
> Table.qualify does not handle dialect diferences
> ------------------------------------------------
>
> Key: HHH-1476
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1476
> Project: Hibernate3
> Issue Type: Bug
> Components: core
> Environment: Hibernate 3.1.2
> SQL Server 2000
> Reporter: Justin Kolb
> Attachments: informix-table-qname-patch-NPAC-vs-v324sp1.diff, informix-table-qname-patch-NPAC.diff, informix-table-qname-patch.diff
>
>
> The fix for HHH-699 caused me to discover that Hibernate isn't handling qualifying table names properly. It can be inferred from HHH-699 that not all databases are similar in this respect so I think this should be added to the dialect handling. From my short research I have the following 3 cases:
> SQL Server: database.owner.table
> MySQL: database.table (no schemas it seems)
> Most others: catalog.schema.table
> SQL Server also allows for "database..table" since it does not have schemas but does allow you to write queries that cross databases similar to how you can cross schemas in other database servers.
> Testing on Postgres though I determined that it does not allow "catalog..table" and will only accept "catalog.schema.table", so it dos not match up with SQL Server in this respect. If you write "catalog.table" it thinks you are trying to use a schema so it does not match up with MySQL in this respect.
> So right now only MySQL and SQL Server are the non standard compliant databases. Before 3.1 beta 1, SQL Server was handled correctly; then after that only MySQL was handled correctly.
> I'm not sure how much work it would take to make this change.
--
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
18 years, 4 months
[Hibernate-JIRA] Updated: (HHH-1476) Table.qualify does not handle dialect diferences
by Mike A. Meyer (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1476?page=c... ]
Mike A. Meyer updated HHH-1476:
-------------------------------
Attachment: informix-table-qname-patch-NPAC.diff
I have modified the patch to retain the public API of the Table class. This one is against the current head revision, I will post a different one for v3.2.4sp1.
> Table.qualify does not handle dialect diferences
> ------------------------------------------------
>
> Key: HHH-1476
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1476
> Project: Hibernate3
> Issue Type: Bug
> Components: core
> Environment: Hibernate 3.1.2
> SQL Server 2000
> Reporter: Justin Kolb
> Attachments: informix-table-qname-patch-NPAC.diff, informix-table-qname-patch.diff
>
>
> The fix for HHH-699 caused me to discover that Hibernate isn't handling qualifying table names properly. It can be inferred from HHH-699 that not all databases are similar in this respect so I think this should be added to the dialect handling. From my short research I have the following 3 cases:
> SQL Server: database.owner.table
> MySQL: database.table (no schemas it seems)
> Most others: catalog.schema.table
> SQL Server also allows for "database..table" since it does not have schemas but does allow you to write queries that cross databases similar to how you can cross schemas in other database servers.
> Testing on Postgres though I determined that it does not allow "catalog..table" and will only accept "catalog.schema.table", so it dos not match up with SQL Server in this respect. If you write "catalog.table" it thinks you are trying to use a schema so it does not match up with MySQL in this respect.
> So right now only MySQL and SQL Server are the non standard compliant databases. Before 3.1 beta 1, SQL Server was handled correctly; then after that only MySQL was handled correctly.
> I'm not sure how much work it would take to make this change.
--
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
18 years, 4 months
[Hibernate-JIRA] Commented: (HHH-1476) Table.qualify does not handle dialect diferences
by Mike A. Meyer (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1476?page=c... ]
Mike A. Meyer commented on HHH-1476:
------------------------------------
changing the public API helps to prevent future misuse, but it is not actually necessary.
> Table.qualify does not handle dialect diferences
> ------------------------------------------------
>
> Key: HHH-1476
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1476
> Project: Hibernate3
> Issue Type: Bug
> Components: core
> Environment: Hibernate 3.1.2
> SQL Server 2000
> Reporter: Justin Kolb
> Attachments: informix-table-qname-patch.diff
>
>
> The fix for HHH-699 caused me to discover that Hibernate isn't handling qualifying table names properly. It can be inferred from HHH-699 that not all databases are similar in this respect so I think this should be added to the dialect handling. From my short research I have the following 3 cases:
> SQL Server: database.owner.table
> MySQL: database.table (no schemas it seems)
> Most others: catalog.schema.table
> SQL Server also allows for "database..table" since it does not have schemas but does allow you to write queries that cross databases similar to how you can cross schemas in other database servers.
> Testing on Postgres though I determined that it does not allow "catalog..table" and will only accept "catalog.schema.table", so it dos not match up with SQL Server in this respect. If you write "catalog.table" it thinks you are trying to use a schema so it does not match up with MySQL in this respect.
> So right now only MySQL and SQL Server are the non standard compliant databases. Before 3.1 beta 1, SQL Server was handled correctly; then after that only MySQL was handled correctly.
> I'm not sure how much work it would take to make this change.
--
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
18 years, 4 months
[Hibernate-JIRA] Commented: (HHH-1476) Table.qualify does not handle dialect diferences
by Max Rydahl Andersen (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1476?page=c... ]
Max Rydahl Andersen commented on HHH-1476:
------------------------------------------
is it really necessary to change public api on Table to support this ?!
> Table.qualify does not handle dialect diferences
> ------------------------------------------------
>
> Key: HHH-1476
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1476
> Project: Hibernate3
> Issue Type: Bug
> Components: core
> Environment: Hibernate 3.1.2
> SQL Server 2000
> Reporter: Justin Kolb
> Attachments: informix-table-qname-patch.diff
>
>
> The fix for HHH-699 caused me to discover that Hibernate isn't handling qualifying table names properly. It can be inferred from HHH-699 that not all databases are similar in this respect so I think this should be added to the dialect handling. From my short research I have the following 3 cases:
> SQL Server: database.owner.table
> MySQL: database.table (no schemas it seems)
> Most others: catalog.schema.table
> SQL Server also allows for "database..table" since it does not have schemas but does allow you to write queries that cross databases similar to how you can cross schemas in other database servers.
> Testing on Postgres though I determined that it does not allow "catalog..table" and will only accept "catalog.schema.table", so it dos not match up with SQL Server in this respect. If you write "catalog.table" it thinks you are trying to use a schema so it does not match up with MySQL in this respect.
> So right now only MySQL and SQL Server are the non standard compliant databases. Before 3.1 beta 1, SQL Server was handled correctly; then after that only MySQL was handled correctly.
> I'm not sure how much work it would take to make this change.
--
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
18 years, 4 months
[Hibernate-JIRA] Commented: (HHH-817) Aggregate projection aliases should not be applied to where-clause
by Ittai Zeidman (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-817?page=co... ]
Ittai Zeidman commented on HHH-817:
-----------------------------------
Hi,
this bug needs to be changed to 'Critical' as when using mapped entities you need to use the criteria.setResultTransformer(CriteriaSpecification.ALIAS_TO_ENTITY_MAP) method to recieve the pojo's data back in a hashmap. the 'CriteriaSpecification.ALIAS_TO_ENTITY_MAP' implementation only converts the properties with aliases to the hashmap, a behavior i think is a different bug. Seeing as this is the only way to get into the hash the required property you have to 'choose' between using the property in the select clause or in the where clause. this is definitely a critical problem.
Thanks
> Aggregate projection aliases should not be applied to where-clause
> ------------------------------------------------------------------
>
> Key: HHH-817
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-817
> Project: Hibernate3
> Issue Type: Bug
> Components: core
> Affects Versions: 3.0.5
> Environment: Oracle 9.2.0.6, Hibernate 3.0.5, Spring Framework 1.2.2 based application working on Jakarta Tomcat 5.0.28
> Reporter: Michal Jastak
> Priority: Minor
> Attachments: HHH-817.patch
>
>
> following java code:
> protected Entity loadEntityLightweight(Serializable entityId) throws DataAccessException {
> Criteria criteria = getSession().createCriteria(Entity.class);
> ProjectionList projectionList = Projections.projectionList();
> projectionList.add(Property.forName(BaseEntity.PROP_ID), BaseEntity.PROP_ID);
> projectionList.add(Property.forName(BaseEntity.PROP_TYPE), BaseEntity.PROP_TYPE);
> criteria.setProjection(projectionList);
> criteria.add(Restrictions.eq(BaseEntity.PROP_ID, entityId));
> criteria.setResultTransformer(new AliasToBeanResultTransformer(Entity.class));
> return (Entity) criteria.uniqueResult();
> }
> generates following SQL query:
> select this_.id as y0_, this_.type as y1_ from entities this_ left outer join facilities this_1_ on this_.id=this_1_.id left outer join users this_2_ on this_.id=this_2_.id left outer join addresses address2_ on this_.address_id=address2_.id left outer join entities entity3_ on this_2_.employer_id=entity3_.id left outer join facilities entity3_1_ on entity3_.id=entity3_1_.id left outer join users entity3_2_ on entity3_.id=entity3_2_.id where y0_=?
> y0_ = ? expression in where clause is causing a 904 error on Oracle 9:
> ORA-00904: "Y0_": invalid identifier
> hibernate dialect: org.hibernate.dialect.Oracle9Dialect
> mapping for Entity class:
> <?xml version="1.0"?>
> <!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN"
> "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
> <hibernate-mapping default-lazy="false" default-cascade="save-update">
>
> <class name="Entity" table="entities" mutable="true">
> <id name="id" type="java.lang.Long" unsaved-value="null">
> <generator class="sequence">
> <param name="sequence">entities_id_seq</param>
> </generator>
> </id>
> <many-to-one name="address" class="Address" column="address_id" />
> ...
> <!--
> - Facilities
> -->
> <joined-subclass name="Facility" table="facilities">
> <key column="id" />
> ...
> <set name="users" inverse="true" lazy="true">
> <key column="facility_id" />
> <one-to-many class="User" />
> </set>
> </joined-subclass>
> <!--
> - Users
> -->
> <joined-subclass name="User" table="users" dynamic-insert="true" dynamic-update="true">
> <key column="id" />
> <many-to-one name="employer" class="Entity" column="employer_id" cascade="none" />
> ...
> <set name="userAuthorities" inverse="true" cascade="all-delete-orphan">
> <key column="user_id" />
> <one-to-many class="Authority" />
> </set>
> </joined-subclass>
> </class>
> </hibernate-mapping>
--
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
18 years, 4 months
[Hibernate-JIRA] Updated: (HHH-1476) Table.qualify does not handle dialect diferences
by Mike A. Meyer (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1476?page=c... ]
Mike A. Meyer updated HHH-1476:
-------------------------------
Attachment: informix-table-qname-patch.diff
The following patch resolves this issue for Informix and allows any Dialect implementation to be adapted.
It has been testet on both the current head revision (as of 2007-11-20) und v3.2.4sp1 (the failing non-applicable patch hunk can be ignored safely) used as JPA provider with JBoss 4.2.1-GA and IBM Informix Dynamic Server Version 10.00.FC4.
> Table.qualify does not handle dialect diferences
> ------------------------------------------------
>
> Key: HHH-1476
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1476
> Project: Hibernate3
> Issue Type: Bug
> Components: core
> Environment: Hibernate 3.1.2
> SQL Server 2000
> Reporter: Justin Kolb
> Attachments: informix-table-qname-patch.diff
>
>
> The fix for HHH-699 caused me to discover that Hibernate isn't handling qualifying table names properly. It can be inferred from HHH-699 that not all databases are similar in this respect so I think this should be added to the dialect handling. From my short research I have the following 3 cases:
> SQL Server: database.owner.table
> MySQL: database.table (no schemas it seems)
> Most others: catalog.schema.table
> SQL Server also allows for "database..table" since it does not have schemas but does allow you to write queries that cross databases similar to how you can cross schemas in other database servers.
> Testing on Postgres though I determined that it does not allow "catalog..table" and will only accept "catalog.schema.table", so it dos not match up with SQL Server in this respect. If you write "catalog.table" it thinks you are trying to use a schema so it does not match up with MySQL in this respect.
> So right now only MySQL and SQL Server are the non standard compliant databases. Before 3.1 beta 1, SQL Server was handled correctly; then after that only MySQL was handled correctly.
> I'm not sure how much work it would take to make this change.
--
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
18 years, 4 months
[Hibernate-JIRA] Commented: (EJB-178) JarVisitor.getVisitor does not treat correctly paths with spaces
by Emmanuel Bernard (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/EJB-178?page=co... ]
Emmanuel Bernard commented on EJB-178:
--------------------------------------
Lars, this is a bug in 3.1.0.beta8...
> JarVisitor.getVisitor does not treat correctly paths with spaces
> ----------------------------------------------------------------
>
> Key: EJB-178
> URL: http://opensource.atlassian.com/projects/hibernate/browse/EJB-178
> Project: Hibernate Entity Manager
> Issue Type: Bug
> Components: EntityManager
> Affects Versions: 3.1.0.Beta8
> Environment: Windows XP Professional; Tomcat 5.5.17.
> Reporter: Alexandrino Lucas
> Original Estimate: 15 minutes
> Remaining Estimate: 15 minutes
>
> I'm using Hibernate Entity Manager with a WAR deployed on Tomcat 5.5.17, and I'm getting the following error:
> 11/05/2006 16:12:43 org.hibernate.ejb.packaging.FileZippedJarVisitor doProcessElements
> WARNING: Unable to find file (ignored): file:/C:/Program%20Files/Apache%20Software%20Foundation/Tomcat%205.5/webapps/[REST OMITTED]
> java.util.zip.ZipException: Access is denied
> at java.util.zip.ZipFile.open(Native Method)
> at java.util.zip.ZipFile.<init>(Unknown Source)
> at java.util.jar.JarFile.<init>(Unknown Source)
> at java.util.jar.JarFile.<init>(Unknown Source)
> at org.hibernate.ejb.packaging.FileZippedJarVisitor.doProcessElements(FileZippedJarVisitor.java:34)
> at org.hibernate.ejb.packaging.JarVisitor.getMatchingEntries(JarVisitor.java:208)
> at org.hibernate.ejb.Ejb3Configuration.addMetadataFromVisitor(Ejb3Configuration.java:201)
> at org.hibernate.ejb.Ejb3Configuration.createEntityManagerFactory(Ejb3Configuration.java:183)
> at org.hibernate.ejb.HibernatePersistence.createEntityManagerFactory(HibernatePersistence.java:114)
> at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:37)
> [MORE...]
> Two strange things: 1) the directory exists; 2) Hibernate is treating the path as being part of a JAR file. I found the cause of the problem when analysing org.hibernate.ejb.packaging.JarVisitor.getVisitor(URL, Filter[]):
> File file = new File( jarUrl.getFile() );
> if ( file.isDirectory() ) {
> return new ExplodedJarVisitor( jarUrl, filters );
> }
> else {
> return new FileZippedJarVisitor( jarUrl, filters );
> }
> As my path has some spaces, jarUrl.getFile() returns "/C:/Program%20Files/Apache%20Software%20Foundation/Tomcat%205.5/webapps/[REST OMITTED]", which is not a directory, because of the "%20"'s. The specification of the java.net.URL class says: "The URL class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL."
> Although I did not have the time to build the project with it, I think that jarUrl.toURI().getPath() would solve the problem. Here is a snippet to prove it:
> import java.io.File;
> import java.net.URL;
> public class Main
> {
> public static void main(
> String[] args )
> throws Exception
> {
> URL url = new URL(
> "file:///C:/Program%20Files/Apache%20Software%20Foundation/Tomcat%205.5/webapps" );
> System.out.println( "url.getFile()" );
> System.out.println( url.getFile() );
> System.out.println( new File( url.getFile() ).isDirectory() );
> System.out.println();
> System.out.println();
> System.out.println();
> System.out.println( "url.toURI().getPath()" );
> System.out.println( url.toURI().getPath() );
> System.out.println( new File( url.toURI().getPath() ).isDirectory() );
> }
> }
--
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
18 years, 4 months