hibernate-issues — Hibernate JIRA Notifications

[Hibernate-issues] [Hibernate-JIRA] Resolved: (HHH-1763) Bug in InputStream org.hibernate.util.ConfigHelper.getResourceAsStream(String resource)

[Emmanuel B. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1763?page=all ]
     
Emmanuel Bernard resolved HHH-1763:
-----------------------------------

    Fix Version: 3.2.0
     Resolution: Fixed
      Assign To: Emmanuel Bernard

thanks

> Bug in InputStream org.hibernate.util.ConfigHelper.getResourceAsStream(String resource)
> ---------------------------------------------------------------------------------------
>
>          Key: HHH-1763
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1763
>      Project: Hibernate3
>         Type: Bug

>   Components: core
>     Versions: 3.1.2
>     Reporter: Ondrej Svetlik
>     Assignee: Emmanuel Bernard
>      Fix For: 3.2.0

>
> Original Estimate: 5 minutes
>         Remaining: 5 minutes
>
> Class org.hibernate.util.ConfigHelper starting at line 137:
> 		if (classLoader!=null) {
> 			stream = classLoader.getResourceAsStream( stripped );
> 		}
> 		if ( stream == null ) {
> 			Environment.class.getResourceAsStream( resource );
> 		}
> 		if ( stream == null ) {
> 			stream = Environment.class.getClassLoader().getResourceAsStream( stripped );
> 		}
> Shouldn't the Environment.class.getResourceAsStream() return value be also assigned?

-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HHH-1763) Bug in InputStream org.hibernate.util.ConfigHelper.getResourceAsStream(String resource)

[Ondrej S. (JIRA) <no...@at...>]

Bug in InputStream org.hibernate.util.ConfigHelper.getResourceAsStream(String resource)
---------------------------------------------------------------------------------------

         Key: HHH-1763
         URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1763
     Project: Hibernate3
        Type: Bug

  Components: core  
    Versions: 3.1.2    
    Reporter: Ondrej Svetlik


Class org.hibernate.util.ConfigHelper starting at line 137:
		if (classLoader!=null) {
			stream = classLoader.getResourceAsStream( stripped );
		}
		if ( stream == null ) {
			Environment.class.getResourceAsStream( resource );
		}
		if ( stream == null ) {
			stream = Environment.class.getClassLoader().getResourceAsStream( stripped );
		}

Shouldn't the Environment.class.getResourceAsStream() return value be also assigned?

-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Updated: (HHH-1750) Exception ORA-01000 too many open cursors by generated="insert"

[Benoit Goudreault-E. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1750?page=all ]

Benoit Goudreault-Emond updated HHH-1750:
-----------------------------------------

    Attachment: HHH-1750.patch

I've tracked down the problem to AbstractEntityPersister's processGeneratedProperties() method.  The ResultSet and PreparedStatement were being leaked.

The attached patch is applicable against 3.1.3.  It works for me.

> Exception ORA-01000 too many open cursors by generated="insert"
> ---------------------------------------------------------------
>
>          Key: HHH-1750
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1750
>      Project: Hibernate3
>         Type: Bug

>  Environment: Hibernate3, Oracle10g
>     Reporter: Andreas Dornhof
>  Attachments: HHH-1750.patch
>
>
> When creating  more as 300 Object in Oracle with insert="false" and generated="insert" by property - Tag in Mapping-File
> causes an ORA-01000  "too many open cursors"...
> It is executed using the following Java code:
> SessionFactory sessionFactory;
>     	
>     	try {
>             // Create the SessionFactory from hibernate.cfg.xml
>             sessionFactory = new Configuration().
>             						configure().
>             						buildSessionFactory();
>         } catch (Throwable ex) {
>             // Make sure you log the exception, as it might be swallowed
>             System.err.println("Initial SessionFactory creation failed." + ex);
>             throw new ExceptionInInitializerError(ex);
>         }
>     
>         try{
>     
>         	for (int i = 0; i <= 301; i++) {
>         		
>         	Session session = sessionFactory.getCurrentSession();
>         	Transaction tx = session.beginTransaction();
> 							
> 	        Test test = new Test();
> 	        session.save(test);
> 	        
> 	        tx.commit();
> 	        
>         	}
>     
> 		    } catch (Exception e) {
> 				System.out.println(e.getMessage()+e.getClass().toString());
> 			}
>     
> And Mapping - File:
> <?xml version="1.0"?>
> <!DOCTYPE hibernate-mapping PUBLIC
> 	"-//Hibernate/Hibernate Mapping DTD//EN"
> 	"http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd" >
> <hibernate-mapping>
> 	<class
> 		name="src.persistence.Test"
> 		table="TEST"
> 		
> 	>
> 		<id name="id" type="java.lang.Long" column="ID"
> 		>
> 			<generator class="sequence">
> 				<param name="sequence">TEST_SEQ</param>
> 			</generator>
> 		</id>
> 		<property
> 			name="created"
> 			column="CREATED"
> 			type="java.util.Date"
> 			not-null="true"
> 			insert="false"
> 			update="false"
> 			generated="insert"
> 		>
> 		</property>
> 	</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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (ANN-343) validator messages in brazilian portuguese

[Guilherme de A. S. (JIRA) <no...@at...>]

validator messages in brazilian portuguese
------------------------------------------

         Key: ANN-343
         URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN=
-343
     Project: Hibernate Annotations
        Type: Improvement

  Components: validator =20
    Versions: 3.2.0.cr1   =20
    Reporter: Guilherme de Azevedo Silveira


Here is the translation.
The file should be named after brazilian portugues (pt-br).

validator.assertFalse=3Dasser=C3=A7=C3=A3o falhou
validator.assertTrue=3Dasser=C3=A7=C3=A3o falhou
validator.future=3Ddeve ser uma data no futuro
validator.length=3Dtamanho deve estar entre {min} e {max}
validator.max=3Ddeve ser menor ou igual a {value}
validator.min=3Ddeve ser maior ou igual a {value}
validator.notNull=3Dn=C3=A3o pode ser nulo
validator.past=3Ddeve ser uma data no passado
validator.pattern=3Ddeve ser v=C3=A1lida de acordo com a express=C3=A3o "{r=
egex}"
validator.range=3Ddeve estar entre {min} e {max}
validator.size=3Dtamanho deve estar entre {min} e {max}
validator.email=3Dn=C3=A3o =C3=A9 um email v=C3=A1lido

--=20
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=
.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (ANN-249) @Range does not support Float/Doubles

[Guilherme de A. S. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/hibernate/browse/ANN-249?page=comments#action_23120 ] 

Guilherme de Azevedo Silveira commented on ANN-249:
---------------------------------------------------

Why not create your own FloatRange/DoubleRange annotation and validator class for your project?

Otherwise the validator project will get packed with custom validators.

> @Range does not support Float/Doubles
> -------------------------------------
>
>          Key: ANN-249
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-249
>      Project: Hibernate Annotations
>         Type: Improvement

>   Components: validator
>     Versions: 3.1beta8
>  Environment: Java1.5.0_06, Hibernate 3.1.2, Annotations 3.1b8
> IBM OS/400 DB2 Database
>     Reporter: Ben Ludkiewicz
>     Priority: Minor

>
>
> I am trying to use the Hibernate Validator to annotate a Float property (a price) but @Range, @Min, and @Max don't seem to support it. When I try adding an 'f' to the end of the number (9999.99f) or cast it ( (float)9999.99 ) I get an type mismatch error saying 'cannot convert a float to an int' (for @Min, @Max) or '... a long' (for @Range). I also tried using a Double instead of a Float and I get the same errors. The Annotations 3.1b8 reference stats that @Min, @Max, and @Range can be applied on a "property (numeric or string representation of a numeric)."
> I posted this on the forums and got the following response from Emannuel:
> [quote="emmanuel"]
> acutally the contraints works on Number but the boundaries have to be of type int currently.
> Open a JIRA issue if it's still an issue for you.
> [/quote]
> Therefore, I am opening this JIRA 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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (ANN-293) Unidirectional @ManyToMany should throw and error or warning when target entity cannot be resolved

[Jeremy N. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/hibernate/browse/ANN-293?page=comments#action_23119 ] 

Jeremy Norris commented on ANN-293:
-----------------------------------

Thank you, that's exactly what I was looking for (I didn't know @CollectionOfElements existed).

> Unidirectional @ManyToMany should throw and error or warning when target entity cannot be resolved
> --------------------------------------------------------------------------------------------------
>
>          Key: ANN-293
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-293
>      Project: Hibernate Annotations
>         Type: Improvement

>     Versions: 3.1beta9
>  Environment: WinXP, MySQL 4.x / 5.x, JDK 1.5_06
>     Reporter: Erik G
>     Assignee: Emmanuel Bernard
>      Fix For: 3.2.0.cr1

>
>
> I have a Unidirectional ManyToMany relationship between a User object and a Task object. Task is actually an interface implemented by AbstractTask and extended by UserTask.
> My original mapping looks like this:
> @ManyToMany(cascade = { CascadeType.PERSIST, CascadeType.MERGE })
> @JoinTable(name = "user_tasks",
>             joinColumns = { @JoinColumn(name = "user_guid") },
>             inverseJoinColumns = { @JoinColumn(name = "task_guid") } )
> public List<Task> getAvailableTasks() {...}
> The correct join table would be created and the "user_guid" column would be created and would be of the correct SQL type for my PK. However, the "task_guid" column would be named "elt" and the sql datatype would be tinyblob (I think Hibernate was probably creating it as a varbinary and MySQL was silently turning it into a tinyblob - see http://dev.mysql.com/doc/refman/5.0/en/silent-column-changes.html ]
> Looking through the documentation for Annotations for @ManyToMany at http://www.hibernate.org/hib_docs/annotations/reference/en/html/entity.html#entity-mapping-association-collections
> I tried changing my mapping to just:
> @ManyToMany(cascade = { CascadeType.PERSIST, CascadeType.MERGE })
> public List<Task> getAvailableTasks() {...}
> This changed the name of my join table per the default naming conventions, but the column names and types were still the same as before.
> Next I tried putting in a targetEntity=AbstractTask.class because this is the superclass of my Task class hierarchy. AbstractTask is marked as a @MappedSuperClass. No luck - same results with both permutations of mappings.
> The solution: I changed the targetEntity=BaseTask.class which is explicity mapped in hibernate.cfg.xml and the DDL was generated as I expected.
> While this is totally user error on my part, it would be nice to have had Annotations throw out an error message or warning of some kind that it would not figure out the targetClass instead of just creating bad DDL and silently ignoring the inverseJoinColumn attribute.
> see original forum posting: http://forum.hibernate.org/viewtopic.php?t=957121

-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Closed: (HHH-1761) Problem persisting <map> elements (values vs. entities)

[Steve E. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1761?page=all ]
     
Steve Ebersole closed HHH-1761:
-------------------------------

    Resolution: Rejected

Please use the user forum for user questions.  Essentially, a value collection cannot be inverse by definition...

> Problem persisting <map> elements (values vs. entities)
> -------------------------------------------------------
>
>          Key: HHH-1761
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1761
>      Project: Hibernate3
>         Type: Bug

>   Components: core
>     Versions: 3.1.3
>  Environment: Hibernate 3.1.3, HSQLDB 1.8.0
>     Reporter: Michael Reviakin
>  Attachments: Test.hbm.xml, Test.java
>
>
> When a Map field (data member) of a persisted object contains "value" elements, changes made to that map are not persisted, as opposite to the situation when a Map field contains "entity" elements (with cascade="all"). 
> I'm not really sure if that it is a bug, but according to "value objects" semantics things should work differently. 
> Lets start with: 
> abstract class AbstractObject { 
>     AbstractObject() {} 
>     Integer id; 
>     Map properties; 
> } 
> assuming that instance of an AbstractObject has unique id and a collection of properties (implemented as a map keyed by property name). 
> Here are two implementations of concrete classes (together with corresponding mappings): 
> //  properties - map of Strings 
> class ObjectA extends AbstractObject { 
>     ObjectA() {} 
> } 
>     <class name="ObjectA" table="OBJECT"> 
>         <id name="id" 
>             column="ID" 
>             access="field"/> 
>         <map name="properties" 
>             table="PROPERTIES" 
>             lazy="false" 
>             inverse="true" 
>             cascade="all,delete-orphan" 
>             fetch="join" 
>             access="field"> 
>             <key column="OBJECT"/> 
>             <map-key column="NAME" type="string"/> 
>             <element column="VALUE" type="string"/>
>         </map> 
>     </class> 
>  
> In ObjectA properties are considered as Map<String, String> while in ObjectB properties will be implemented as Map<String, Property>: 
> //  properties - map of Properties 
> class ObjectB extends AbstractObject { 
>     ObjectB() {} 
> } 
> class Property { 
>     Property() {} 
>     static class Id implements Serializable { 
>         Id() {} 
>         Integer object; 
>         String name; 
>     } 
>     Id id; 
>     String value; 
> } 
>     <class name="ObjectB" table="OBJECT"> 
>         <id name="id" 
>             column="ID" 
>             access="field"/> 
>         <map name="properties" 
>             table="PROPERTIES" 
>             lazy="false" 
>             inverse="true" 
>             cascade="all,delete-orphan" 
>             fetch="join" 
>             access="field"> 
>             <key column="OBJECT"/> 
>             <map-key column="NAME" type="string"/> 
>             <one-to-many class="Property"/>
>         </map> 
>     </class> 
>     <class name="Property" table="PROPERTIES"> 
>         <composite-id 
>             name="id" 
>             class="Property$Id" 
>             access="field"> 
>             <key-property 
>                 name="object" 
>                 type="integer" 
>                 column="OBJECT" 
>                 access="field" 
>             /> 
>             <key-property 
>                 name="name" 
>                 type="string" 
>                 column="NAME" 
>                 access="field" 
>             /> 
>         </composite-id> 
>         <property 
>             name="value" 
>             type="string" 
>             column="VALUE" 
>             access="field" 
>         /> 
>     </class> 
>  
> ObjectA and ObjectB provide two different views for the same table OBJECTS. The main difference here is that ObjectA maps content if the properties as <element column="VALUE" type="string"/> while ObjectB does so by <one-to-many class="Property"/>. 
> Here is where problems starts. Having: 
>         Integer objectId = new Integer(1); 
>         String name = "test"; 
>         AbstractObject object = null; 
>  
> Following code: 
>         object = new ObjectA(); 
>         object.id = objectId; 
>         object.properties = new HashMap(); 
>         String property = "abc"; 
>         object.properties.put(name, property); 
>         session.save(object); 
>  
> absolutely fails to persist the content of properties, while 
>         object = new ObjectB(); 
>         object.id = objectId; 
>         object.properties = new HashMap(); 
>         Property property = new Property(); 
>         property.id = new Property.Id(); 
>         property.id.object = objectId; 
>         property.id.name = name; 
>         property.value = "abc"; 
>         object.properties.put(name, property); 
>         session.save(object); 
>  
> works just fine. 
> Attempting to modify persisted object yields similar results: 
>         object = (AbstractObject)session.get(ObjectA.class, objectId); 
>         object.properties.put(name, "xyz"); 
>         session.save(object); 
>  
> has no effect on the db, when: 
>         object = (AbstractObject)session.get(ObjectB.class, objectId); 
>         Property property = (Property)object.properties.get(name); 
>         property.value = "xyz"; 
>         object.properties.put(name, property); 
>         session.save(object); 
>  
> does what it is supposed to do. 

-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Closed: (HHH-1762) ClassCastException caused by improper casting of property value during place holder resolving of system properties.

[Steve E. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1762?page=all ]
     
Steve Ebersole closed HHH-1762:
-------------------------------

    Resolution: Duplicate

already fixed

> ClassCastException caused by improper casting of property value during place holder resolving of system properties.
> -------------------------------------------------------------------------------------------------------------------
>
>          Key: HHH-1762
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1762
>      Project: Hibernate3
>         Type: Bug

>   Components: core
>     Versions: 3.1.3
>  Environment: WebSphere 5.1, Oracle 8.1.7.1.4, Windows Server 2003
>     Reporter: Andy Verberne
>     Priority: Minor

>
> Original Estimate: 4 hours
>         Remaining: 4 hours
>
> During the initialization of Hibernate the method  "org.hibernate.cfg.Configuration.buildSessionFactory()"  calls the following method where the properties parameter contains all JVM system properties:
> public static void org.hibernate.util.PropertiesHelper.resolvePlaceHolders(Properties properties) {
>           Iterator itr = properties.entrySet().iterator();
>           while ( itr.hasNext() ) {
>               final Map.Entry entry = ( Map.Entry ) itr.next();
>               final String value = ( String ) entry.getValue();
>               if ( value != null ) {
>                    final String resolved = resolvePlaceHolder( value );
>                    if ( !value.equals( resolved ) ) {
>                         if ( resolved == null ) {
>                              itr.remove();
>                         }
>                         else {
>                              entry.setValue( resolved );
>                         }
>                    }
>               }
>           }
>      }
> This will cause a ClassCastException in the statement  "(String)entry.getValue(); " when the following system property exists:
> soapconn.JMSListener={SOAPConnMQGateway$Listener:FF#001=com.ing.jms.listener.JMSListener@773a20f5, SOAPConnMQGateway$Listener:RR#001=com.ing.jms.listener.JMSListener@5d0060ff}
> For this property the entry.getValue() will not return a String object but a java.util.HashMap instead.
> Possible fixes:
> 1) replace "( String ) entry.getValue();" with entry.getValue().toString();
> 2) Check the class type returned by entry.getValue() and only cast when it is a String.
> However, the fact that all system properties are resolved for placeholders is probably not a good design. Only the Hibernate properties should be resolved. System properties not belonging to Hibernate should not be read at all.

-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HHH-1762) ClassCastException caused by improper casting of property value during place holder resolving of system properties.

[Andy V. (JIRA) <no...@at...>]

ClassCastException caused by improper casting of property value during place holder resolving of system properties.
-------------------------------------------------------------------------------------------------------------------

         Key: HHH-1762
         URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1762
     Project: Hibernate3
        Type: Bug

  Components: core  
    Versions: 3.1.3    
 Environment: WebSphere 5.1, Oracle 8.1.7.1.4, Windows Server 2003
    Reporter: Andy Verberne
    Priority: Minor


During the initialization of Hibernate the method  "org.hibernate.cfg.Configuration.buildSessionFactory()"  calls the following method where the properties parameter contains all JVM system properties:

public static void org.hibernate.util.PropertiesHelper.resolvePlaceHolders(Properties properties) {
          Iterator itr = properties.entrySet().iterator();
          while ( itr.hasNext() ) {
              final Map.Entry entry = ( Map.Entry ) itr.next();
              final String value = ( String ) entry.getValue();
              if ( value != null ) {
                   final String resolved = resolvePlaceHolder( value );
                   if ( !value.equals( resolved ) ) {
                        if ( resolved == null ) {
                             itr.remove();
                        }
                        else {
                             entry.setValue( resolved );
                        }
                   }
              }
          }
     }

This will cause a ClassCastException in the statement  "(String)entry.getValue(); " when the following system property exists:

soapconn.JMSListener={SOAPConnMQGateway$Listener:FF#001=com.ing.jms.listener.JMSListener@773a20f5, SOAPConnMQGateway$Listener:RR#001=com.ing.jms.listener.JMSListener@5d0060ff}

For this property the entry.getValue() will not return a String object but a java.util.HashMap instead.

Possible fixes:
1) replace "( String ) entry.getValue();" with entry.getValue().toString();
2) Check the class type returned by entry.getValue() and only cast when it is a String.

However, the fact that all system properties are resolved for placeholders is probably not a good design. Only the Hibernate properties should be resolved. System properties not belonging to Hibernate should not be read at all.



-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HHH-1761) Problem persisting <map> elements (values vs. entities)

[Michael R. (JIRA) <no...@at...>]

Problem persisting <map> elements (values vs. entities)
-------------------------------------------------------

         Key: HHH-1761
         URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1761
     Project: Hibernate3
        Type: Bug

  Components: core  
    Versions: 3.1.3    
 Environment: Hibernate 3.1.3, HSQLDB 1.8.0

    Reporter: Michael Reviakin
 Attachments: Test.hbm.xml, Test.java

When a Map field (data member) of a persisted object contains "value" elements, changes made to that map are not persisted, as opposite to the situation when a Map field contains "entity" elements (with cascade="all"). 

I'm not really sure if that it is a bug, but according to "value objects" semantics things should work differently. 

Lets start with: 

abstract class AbstractObject { 
    AbstractObject() {} 
    Integer id; 
    Map properties; 
} 

assuming that instance of an AbstractObject has unique id and a collection of properties (implemented as a map keyed by property name). 
Here are two implementations of concrete classes (together with corresponding mappings): 

//  properties - map of Strings 
class ObjectA extends AbstractObject { 
    ObjectA() {} 
} 

    <class name="ObjectA" table="OBJECT"> 
        <id name="id" 
            column="ID" 
            access="field"/> 

        <map name="properties" 
            table="PROPERTIES" 
            lazy="false" 
            inverse="true" 
            cascade="all,delete-orphan" 
            fetch="join" 
            access="field"> 

            <key column="OBJECT"/> 
            <map-key column="NAME" type="string"/> 
            <element column="VALUE" type="string"/>
        </map> 
    </class> 
 
In ObjectA properties are considered as Map<String, String> while in ObjectB properties will be implemented as Map<String, Property>: 

//  properties - map of Properties 
class ObjectB extends AbstractObject { 
    ObjectB() {} 
} 

class Property { 
    Property() {} 
    static class Id implements Serializable { 
        Id() {} 
        Integer object; 
        String name; 
    } 
    Id id; 
    String value; 
} 

    <class name="ObjectB" table="OBJECT"> 
        <id name="id" 
            column="ID" 
            access="field"/> 

        <map name="properties" 
            table="PROPERTIES" 
            lazy="false" 
            inverse="true" 
            cascade="all,delete-orphan" 
            fetch="join" 
            access="field"> 

            <key column="OBJECT"/> 
            <map-key column="NAME" type="string"/> 
            <one-to-many class="Property"/>
        </map> 
    </class> 

    <class name="Property" table="PROPERTIES"> 
        <composite-id 
            name="id" 
            class="Property$Id" 
            access="field"> 

            <key-property 
                name="object" 
                type="integer" 
                column="OBJECT" 
                access="field" 
            /> 
            <key-property 
                name="name" 
                type="string" 
                column="NAME" 
                access="field" 
            /> 
        </composite-id> 

        <property 
            name="value" 
            type="string" 
            column="VALUE" 
            access="field" 
        /> 
    </class> 
 
ObjectA and ObjectB provide two different views for the same table OBJECTS. The main difference here is that ObjectA maps content if the properties as <element column="VALUE" type="string"/> while ObjectB does so by <one-to-many class="Property"/>. 

Here is where problems starts. Having: 

        Integer objectId = new Integer(1); 
        String name = "test"; 
        AbstractObject object = null; 
 
Following code: 

        object = new ObjectA(); 
        object.id = objectId; 
        object.properties = new HashMap(); 
        String property = "abc"; 
        object.properties.put(name, property); 
        session.save(object); 
 
absolutely fails to persist the content of properties, while 

        object = new ObjectB(); 
        object.id = objectId; 
        object.properties = new HashMap(); 
        Property property = new Property(); 
        property.id = new Property.Id(); 
        property.id.object = objectId; 
        property.id.name = name; 
        property.value = "abc"; 
        object.properties.put(name, property); 
        session.save(object); 
 
works just fine. 

Attempting to modify persisted object yields similar results: 

        object = (AbstractObject)session.get(ObjectA.class, objectId); 
        object.properties.put(name, "xyz"); 
        session.save(object); 
 
has no effect on the db, when: 

        object = (AbstractObject)session.get(ObjectB.class, objectId); 
        Property property = (Property)object.properties.get(name); 
        property.value = "xyz"; 
        object.properties.put(name, property); 
        session.save(object); 
 
does what it is supposed to do. 


-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HBX-663) Missing vm file

[Max R. A. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HBX-663?page=comments#action_23116 ] 

Max Rydahl Andersen commented on HBX-663:
-----------------------------------------

yes, one-to-one is not implemented yet. contributions welcome.

And please remember to use the latest version of the tools (which uses freemarker instead of velocity) if you choose to contribute it.

> Missing vm file
> ---------------
>
>          Key: HBX-663
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-663
>      Project: Hibernate Tools
>         Type: Bug

>     Versions: 3.1beta4
>  Environment: Hibernate 3.2.0.cr1
> Hibernate Annotations 3.1beta9
> Oracle 9
>     Reporter: Erik W. Rasmussen

>
>
> I have a class annotated with a one-to-one mapping to another class. When running the hbm2hbmxml tool the following error results:
> Caused by: org.hibernate.tool.hbm2x.ExporterException: Could not find template with name: hbm/one-to-one.hbm.vm
> 	at org.hibernate.tool.hbm2x.TemplateHelper.getTemplateName(TemplateHelper.java:180)
> 	at org.hibernate.tool.hbm2x.TemplateHelper.processTemplate(TemplateHelper.java:138)
> /Erik

-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HBX-663) Missing vm file

[Erik W. R. (JIRA) <no...@at...>]

Missing vm file
---------------

         Key: HBX-663
         URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-663
     Project: Hibernate Tools
        Type: Bug

    Versions: 3.1beta4    
 Environment: Hibernate 3.2.0.cr1
Hibernate Annotations 3.1beta9
Oracle 9
    Reporter: Erik W. Rasmussen


I have a class annotated with a one-to-one mapping to another class. When running the hbm2hbmxml tool the following error results:

Caused by: org.hibernate.tool.hbm2x.ExporterException: Could not find template with name: hbm/one-to-one.hbm.vm
	at org.hibernate.tool.hbm2x.TemplateHelper.getTemplateName(TemplateHelper.java:180)
	at org.hibernate.tool.hbm2x.TemplateHelper.processTemplate(TemplateHelper.java:138)

/Erik

-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HHH-1760) day sql-function does not exist in MySQL before 4.1.1

[Andrey G. (JIRA) <no...@at...>]

day sql-function does not exist in MySQL before 4.1.1
-----------------------------------------------------

         Key: HHH-1760
         URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1760
     Project: Hibernate3
        Type: Improvement

  Components: core  
    Versions: 3.1.3    
 Environment: Hibernate 3.1.3, MySQL 4.0.20d
    Reporter: Andrey Grebnev


Hello

MySQLDialect.java has the following definition: 

        registerFunction("day", new StandardSQLFunction("day", Hibernate.INTEGER) ); 

but we can read in MySQL documentation that

        DAY(date) 
        DAY() is a synonym for DAYOFMONTH(). It is available as of MySQL 4.1.1. 

so before mysql 4.1.1 we does not have day function.

I offer to replace above line in Dialect with the following

        registerFunction("day", new StandardSQLFunction("dayofmonth", Hibernate.INTEGER) ); 

In this way we will have compatibility with MySql versions both before 4.1.1 and after 4.1.1.

Thanks.

-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HHH-1759) ClasscQueryTranslator do not make SQL Function substitution

[Andrey G. (JIRA) <no...@at...>]

ClasscQueryTranslator do not make SQL Function substitution
-----------------------------------------------------------

         Key: HHH-1759
         URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1759
     Project: Hibernate3
        Type: Bug

  Components: query-hql  
    Versions: 3.1.3    
 Environment: Hibernate 3.1.3, JDK 1.5.0_05, MySQL 4.0.20d, Tomcat 5.5.15
    Reporter: Andrey Grebnev


I have already asked about this problem in forum http://forum.hibernate.org/viewtopic.php?t=959442 but I did not get answer.
below my text from forum's question:

Hello 

I have faced with the following problem. I use Hibernate-3.1.3 with ClassicQueryTranslatorFactory under MySQL 4.0.20d. 

I need the SQL function "day". MySQL 4.0 does not have day function, but it has equal "dayofmonth". MySQLDialect.java has the following definition: 

        registerFunction("day", new StandardSQLFunction("day", Hibernate.INTEGER) ); 


In order to have compatibility both with MySQL 4.0 and above I have written my own Dialect which override day function in the following way: 

        registerFunction("day", new StandardSQLFunction("dayofmonth", Hibernate.INTEGER) ); 


With ASTQueryTranslator this dialect works corrrectly, but with Classic one it does not work!!! 

I have examined Hibernate SRC and have found out that we have follwing code in the org.hibernate.hql.classic.SelectParser: 126 


        else if ( getFunction( lctoken, q ) != null && token.equals( q.unalias( token ) ) ) { 
            // the name of an SQL function 
            if ( !ready ) throw new QueryException( ", expected before aggregate function in SELECT: " + token ); 
            aggregate = true; 
            aggregateAddSelectScalar = true; 
            aggregateFuncTokenList.add( lctoken ); 
            ready = false; 
            q.appendScalarSelectToken( token ); 
            if ( !aggregateHasArgs( lctoken, q ) ) { 
                q.addSelectScalar( aggregateType( aggregateFuncTokenList, null, q ) ); 
                if ( !aggregateFuncNoArgsHasParenthesis( lctoken, q ) ) { 
                    aggregateFuncTokenList.removeLast(); 
                    if ( aggregateFuncTokenList.size() < 1 ) { 
                        aggregate = false; 
                        ready = false; 
                    } 
                    else { 
                        ready = true; 
                    } 
                } 
            } 
        } 
 


we can see that we call 
q.appendScalarSelectToken( token ); 

function with original token, we do not use "render" method of org.hibernate.dialect.function.StandardSQLFunction. 

Is this a bug of classic translator? 

I am obliged to use Classic translator because Weblogic's problems with AST. Please give me an advice. 

Thanks beforehand.


-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Updated: (HHH-1758) auto-import attribute on class entity of the XML mapping document

[Chandrashekara K A (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1758?page=all ]

Chandrashekara K A updated HHH-1758:
------------------------------------

    Attachment: 1758.patch

Code changes : in patch format

> auto-import attribute on class entity of the XML mapping document
> -----------------------------------------------------------------
>
>          Key: HHH-1758
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1758
>      Project: Hibernate3
>         Type: Improvement

>   Components: core
>     Versions: 3.0.5
>  Environment: Any
>     Reporter: Chandrashekara K A
>  Attachments: 1758.patch
>
> Original Estimate: 0 minutes
>         Remaining: 0 minutes
>
> Its nice if the auto-import attribute was supported on the class tag of the hibernate mapping file so that any mapping level autro-import specification can be overridden by a class. Its also quite useful to limit the problem of having to specify the class name completely in querties only to a select set of classes. (Of course any code generation tools like xdoclet must be modified to support this to be very useful - I have done that for our project).
> I have attached the changes to class HbmBinder (around line 541 to code that says)
> ----------CODE BEFORE--------------
> 		if(mappings.isAutoImport() && entity.getEntityName().indexOf( '.' ) > 0) {
> 			mappings.addImport( entity.getEntityName(), StringHelper.unqualify( entity
> 				.getEntityName() ) );
> 		}
> --------------------------------------
> ----------CODE AFTER----------------
> 		boolean unqualify = mappings.isAutoImport() && entity.getEntityName().indexOf( '.' ) > 0;
> 		
> 		Attribute autoImportNode = node.attribute("auto-import");
> 		
> 		if(autoImportNode != null)
> 		{
> 			unqualify = autoImportNode.getValue().equalsIgnoreCase("true");
> 		}
> 		
> 		if(unqualify) {
> 			mappings.addImport( entity.getEntityName(), StringHelper.unqualify( entity
> 				.getEntityName() ) );
> 		}
> ---------------------------------------

-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HHH-1758) auto-import attribute on class entity of the XML mapping document

[Chandrashekara K A (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1758?page=comments#action_23114 ] 

Chandrashekara K A commented on HHH-1758:
-----------------------------------------

Sorry for the incomplete spec of the class : HbmBinder is org.hibernate.cfg.HbmBinder.


> auto-import attribute on class entity of the XML mapping document
> -----------------------------------------------------------------
>
>          Key: HHH-1758
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1758
>      Project: Hibernate3
>         Type: Improvement

>   Components: core
>     Versions: 3.0.5
>  Environment: Any
>     Reporter: Chandrashekara K A

>
> Original Estimate: 0 minutes
>         Remaining: 0 minutes
>
> Its nice if the auto-import attribute was supported on the class tag of the hibernate mapping file so that any mapping level autro-import specification can be overridden by a class. Its also quite useful to limit the problem of having to specify the class name completely in querties only to a select set of classes. (Of course any code generation tools like xdoclet must be modified to support this to be very useful - I have done that for our project).
> I have attached the changes to class HbmBinder (around line 541 to code that says)
> ----------CODE BEFORE--------------
> 		if(mappings.isAutoImport() && entity.getEntityName().indexOf( '.' ) > 0) {
> 			mappings.addImport( entity.getEntityName(), StringHelper.unqualify( entity
> 				.getEntityName() ) );
> 		}
> --------------------------------------
> ----------CODE AFTER----------------
> 		boolean unqualify = mappings.isAutoImport() && entity.getEntityName().indexOf( '.' ) > 0;
> 		
> 		Attribute autoImportNode = node.attribute("auto-import");
> 		
> 		if(autoImportNode != null)
> 		{
> 			unqualify = autoImportNode.getValue().equalsIgnoreCase("true");
> 		}
> 		
> 		if(unqualify) {
> 			mappings.addImport( entity.getEntityName(), StringHelper.unqualify( entity
> 				.getEntityName() ) );
> 		}
> ---------------------------------------

-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HHH-1758) auto-import attribute on class entity of the XML mapping document

[Chandrashekara K A (JIRA) <no...@at...>]

auto-import attribute on class entity of the XML mapping document
-----------------------------------------------------------------

         Key: HHH-1758
         URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1758
     Project: Hibernate3
        Type: Improvement

  Components: core  
    Versions: 3.0.5    
 Environment: Any
    Reporter: Chandrashekara K A


Its nice if the auto-import attribute was supported on the class tag of the hibernate mapping file so that any mapping level autro-import specification can be overridden by a class. Its also quite useful to limit the problem of having to specify the class name completely in querties only to a select set of classes. (Of course any code generation tools like xdoclet must be modified to support this to be very useful - I have done that for our project).

I have attached the changes to class HbmBinder (around line 541 to code that says)
----------CODE BEFORE--------------
		if(mappings.isAutoImport() && entity.getEntityName().indexOf( '.' ) > 0) {
			mappings.addImport( entity.getEntityName(), StringHelper.unqualify( entity
				.getEntityName() ) );
		}
--------------------------------------

----------CODE AFTER----------------
		boolean unqualify = mappings.isAutoImport() && entity.getEntityName().indexOf( '.' ) > 0;
		
		Attribute autoImportNode = node.attribute("auto-import");
		
		if(autoImportNode != null)
		{
			unqualify = autoImportNode.getValue().equalsIgnoreCase("true");
		}
		
		if(unqualify) {
			mappings.addImport( entity.getEntityName(), StringHelper.unqualify( entity
				.getEntityName() ) );
		}

---------------------------------------


-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (ANN-293) Unidirectional @ManyToMany should throw and error or warning when target entity cannot be resolved

[Christian B. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/hibernate/browse/ANN-293?page=comments#action_23113 ] 

Christian Bauer commented on ANN-293:
-------------------------------------

A OneToMany to an Embeddable type is completely broken, conceptually. You want a CollectionOfElements. If it worked once before, it was a bug.


> Unidirectional @ManyToMany should throw and error or warning when target entity cannot be resolved
> --------------------------------------------------------------------------------------------------
>
>          Key: ANN-293
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-293
>      Project: Hibernate Annotations
>         Type: Improvement

>     Versions: 3.1beta9
>  Environment: WinXP, MySQL 4.x / 5.x, JDK 1.5_06
>     Reporter: Erik G
>     Assignee: Emmanuel Bernard
>      Fix For: 3.2.0.cr1

>
>
> I have a Unidirectional ManyToMany relationship between a User object and a Task object. Task is actually an interface implemented by AbstractTask and extended by UserTask.
> My original mapping looks like this:
> @ManyToMany(cascade = { CascadeType.PERSIST, CascadeType.MERGE })
> @JoinTable(name = "user_tasks",
>             joinColumns = { @JoinColumn(name = "user_guid") },
>             inverseJoinColumns = { @JoinColumn(name = "task_guid") } )
> public List<Task> getAvailableTasks() {...}
> The correct join table would be created and the "user_guid" column would be created and would be of the correct SQL type for my PK. However, the "task_guid" column would be named "elt" and the sql datatype would be tinyblob (I think Hibernate was probably creating it as a varbinary and MySQL was silently turning it into a tinyblob - see http://dev.mysql.com/doc/refman/5.0/en/silent-column-changes.html ]
> Looking through the documentation for Annotations for @ManyToMany at http://www.hibernate.org/hib_docs/annotations/reference/en/html/entity.html#entity-mapping-association-collections
> I tried changing my mapping to just:
> @ManyToMany(cascade = { CascadeType.PERSIST, CascadeType.MERGE })
> public List<Task> getAvailableTasks() {...}
> This changed the name of my join table per the default naming conventions, but the column names and types were still the same as before.
> Next I tried putting in a targetEntity=AbstractTask.class because this is the superclass of my Task class hierarchy. AbstractTask is marked as a @MappedSuperClass. No luck - same results with both permutations of mappings.
> The solution: I changed the targetEntity=BaseTask.class which is explicity mapped in hibernate.cfg.xml and the DDL was generated as I expected.
> While this is totally user error on my part, it would be nice to have had Annotations throw out an error message or warning of some kind that it would not figure out the targetClass instead of just creating bad DDL and silently ignoring the inverseJoinColumn attribute.
> see original forum posting: http://forum.hibernate.org/viewtopic.php?t=957121

-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (ANN-293) Unidirectional @ManyToMany should throw and error or warning when target entity cannot be resolved

[Jeremy N. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/hibernate/browse/ANN-293?page=comments#action_23112 ] 

Jeremy Norris commented on ANN-293:
-----------------------------------

The checkin for this fix (http://fisheye.jboss.org/changelog/Hibernate?cs=9837) seems to have caused this issue: http://forum.hibernate.org/viewtopic.php?t=959542

It seemed like a valid thing to be able to map @OneToMany to an @Embeddable type.  Thoughts?

> Unidirectional @ManyToMany should throw and error or warning when target entity cannot be resolved
> --------------------------------------------------------------------------------------------------
>
>          Key: ANN-293
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-293
>      Project: Hibernate Annotations
>         Type: Improvement

>     Versions: 3.1beta9
>  Environment: WinXP, MySQL 4.x / 5.x, JDK 1.5_06
>     Reporter: Erik G
>     Assignee: Emmanuel Bernard
>      Fix For: 3.2.0.cr1

>
>
> I have a Unidirectional ManyToMany relationship between a User object and a Task object. Task is actually an interface implemented by AbstractTask and extended by UserTask.
> My original mapping looks like this:
> @ManyToMany(cascade = { CascadeType.PERSIST, CascadeType.MERGE })
> @JoinTable(name = "user_tasks",
>             joinColumns = { @JoinColumn(name = "user_guid") },
>             inverseJoinColumns = { @JoinColumn(name = "task_guid") } )
> public List<Task> getAvailableTasks() {...}
> The correct join table would be created and the "user_guid" column would be created and would be of the correct SQL type for my PK. However, the "task_guid" column would be named "elt" and the sql datatype would be tinyblob (I think Hibernate was probably creating it as a varbinary and MySQL was silently turning it into a tinyblob - see http://dev.mysql.com/doc/refman/5.0/en/silent-column-changes.html ]
> Looking through the documentation for Annotations for @ManyToMany at http://www.hibernate.org/hib_docs/annotations/reference/en/html/entity.html#entity-mapping-association-collections
> I tried changing my mapping to just:
> @ManyToMany(cascade = { CascadeType.PERSIST, CascadeType.MERGE })
> public List<Task> getAvailableTasks() {...}
> This changed the name of my join table per the default naming conventions, but the column names and types were still the same as before.
> Next I tried putting in a targetEntity=AbstractTask.class because this is the superclass of my Task class hierarchy. AbstractTask is marked as a @MappedSuperClass. No luck - same results with both permutations of mappings.
> The solution: I changed the targetEntity=BaseTask.class which is explicity mapped in hibernate.cfg.xml and the DDL was generated as I expected.
> While this is totally user error on my part, it would be nice to have had Annotations throw out an error message or warning of some kind that it would not figure out the targetClass instead of just creating bad DDL and silently ignoring the inverseJoinColumn attribute.
> see original forum posting: http://forum.hibernate.org/viewtopic.php?t=957121

-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Closed: (HHH-1757) "Named query not known" with valid <query>. Invalid hibernate-mapping-3.0.dtd

[Max R. A. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1757?page=all ]
     
Max Rydahl Andersen closed HHH-1757:
------------------------------------

    Resolution: Rejected

it works fine ;) (nesting the <query> inside a class prepend the class/entity name to the query name)


> "Named query not known" with valid <query>.  Invalid hibernate-mapping-3.0.dtd
> ------------------------------------------------------------------------------
>
>          Key: HHH-1757
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1757
>      Project: Hibernate3
>         Type: Bug

>     Versions: 3.1.3
>  Environment: Hibernate v3.1.3, MySQL v5.0.21, jdk1.5.0_06
>     Reporter: W. Muir
>     Priority: Minor

>
>
> <query> element in a hibernate mapping file validates against the DTD (http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd) for both cases:
> Case 1: <query> element outside <class>
> <hibernate-mapping>
>     <class name="com.acme.Foo" table="foo">
>         ...
>     </class>
>     <query name="Foo.findBy">
>         <![CDATA[ FROM Foo WHERE ... ]]>
>     </query>
> </hibernate-mapping>
> Case 2:  <query> element inside <class>
> <hibernate-mapping>
>     <class name="com.acme.Foo" table="foo">
>         ...
>         <query name="Foo.findBy">
>             <![CDATA[ FROM Foo WHERE ... ]]>
>         </query>
>     </class>
> </hibernate-mapping>
> However, Case 2 produces a Mapping Exception:
>   
>     org.hibernate.MappingException: Named query not known: Foo.findBy
> when session.getNamedQuery( "Foo.findBy" ) is called.
> If the the exception caused by Case #2 is legit, then the DTD should be changed so mapping xml will not validate when <query> is within <class> element.

-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HHH-1757) "Named query not known" with valid <query>. Invalid hibernate-mapping-3.0.dtd

[W. M. (JIRA) <no...@at...>]

"Named query not known" with valid <query>.  Invalid hibernate-mapping-3.0.dtd
------------------------------------------------------------------------------

         Key: HHH-1757
         URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1757
     Project: Hibernate3
        Type: Bug

    Versions: 3.1.3    
 Environment: Hibernate v3.1.3, MySQL v5.0.21, jdk1.5.0_06
    Reporter: W. Muir
    Priority: Minor


<query> element in a hibernate mapping file validates against the DTD (http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd) for both cases:

Case 1: <query> element outside <class>

<hibernate-mapping>
    <class name="com.acme.Foo" table="foo">
        ...
    </class>

    <query name="Foo.findBy">
        <![CDATA[ FROM Foo WHERE ... ]]>
    </query>
</hibernate-mapping>

Case 2:  <query> element inside <class>

<hibernate-mapping>
    <class name="com.acme.Foo" table="foo">
        ...
        <query name="Foo.findBy">
            <![CDATA[ FROM Foo WHERE ... ]]>
        </query>
    </class>
</hibernate-mapping>

However, Case 2 produces a Mapping Exception:
  
    org.hibernate.MappingException: Named query not known: Foo.findBy

when session.getNamedQuery( "Foo.findBy" ) is called.

If the the exception caused by Case #2 is legit, then the DTD should be changed so mapping xml will not validate when <query> is within <class> element.


-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HHH-511) reattach object from same session

[Jose P. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-511?page=comments#action_23110 ] 

Jose Peleteiro commented on HHH-511:
------------------------------------

+1
Please, consider this one.

> reattach object from same session
> ---------------------------------
>
>          Key: HHH-511
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-511
>      Project: Hibernate3
>         Type: Bug

>   Components: core
>     Reporter: Gavin King
>     Priority: Minor

>
>
> http://forum.hibernate.org/viewtopic.php?p=2231400#2231400
> There is a problem when you reattach a collection to the same session that it was previously attached to, after calling clear(). Hibernate checks the collections session reference, at reattach and concludes it is  already attached.

-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HHH-1756) Proxy objects are not removed from the BatchFetchQueue during a session evict

[Vadim P. (JIRA) <no...@at...>]

Proxy objects are not removed from the BatchFetchQueue during a session evict
-----------------------------------------------------------------------------

         Key: HHH-1756
         URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1756
     Project: Hibernate3
        Type: Bug

 Environment: Windows, Sybase, Hibernate Annotations
    Reporter: Vadim Pertsovskiy


When an entity loads, it initializes its children proxies and adds them to the BatchFetchQueue. The next time any of the proxies classes are loaded, hibernate retrieves additional objects rather then just the requested one. This works great, except if the user wants to evict the proxy  from the BatchFetchQueue. Hibernate, incorrectly, does not do it. Once a proxy is added to the BatchFetchQueue, it's never removed unless the object is loaded. 

To fix the problem, we've altered the SessionImpl class. During a proxy remove, the proxy is also removed from the BatchFetchQueue. 

	public Object removeProxy(EntityKey key) {
		getBatchFetchQueue().removeBatchLoadableEntityKey(key);
		getBatchFetchQueue().removeSubselect(key);

		return proxiesByKey.remove(key);		
	}

-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HHH-1746) NullPointerException at IdentNode.resolveAsNakedComponentPropertyRefLHS(IdentNode.java:195

[Greg B. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1746?page=comments#action_23109 ] 

Greg Barton commented on HHH-1746:
----------------------------------

I've also encountered this NPE.

> NullPointerException at IdentNode.resolveAsNakedComponentPropertyRefLHS(IdentNode.java:195
> ------------------------------------------------------------------------------------------
>
>          Key: HHH-1746
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1746
>      Project: Hibernate3
>         Type: Bug

>   Components: query-hql
>     Versions: 3.2.0 cr1
>     Reporter: Igor A Tarasov

>
>
>  java.lang.NullPointerException
> 	at org.hibernate.hql.ast.tree.IdentNode.resolveAsNakedComponentPropertyRefLHS(IdentNode.java:195)
> 	at org.hibernate.hql.ast.tree.IdentNode.resolve(IdentNode.java:85)
> 	at org.hibernate.hql.ast.tree.DotNode.resolveFirstChild(DotNode.java:139)
> 	at org.hibernate.hql.ast.HqlSqlWalker.lookupProperty(HqlSqlWalker.java:469)
> 	at org.hibernate.hql.antlr.HqlSqlBaseWalker.addrExpr(HqlSqlBaseWalker.java:4316)
> 	at org.hibernate.hql.antlr.HqlSqlBaseWalker.expr(HqlSqlBaseWalker.java:1211)
> 	at org.hibernate.hql.antlr.HqlSqlBaseWalker.exprOrSubquery(HqlSqlBaseWalker.java:4032)
> 	at org.hibernate.hql.antlr.HqlSqlBaseWalker.comparisonExpr(HqlSqlBaseWalker.java:3518)
> 	at org.hibernate.hql.antlr.HqlSqlBaseWalker.logicalExpr(HqlSqlBaseWalker.java:1758)
> 	at org.hibernate.hql.antlr.HqlSqlBaseWalker.logicalExpr(HqlSqlBaseWalker.java:1683)
> 	at org.hibernate.hql.antlr.HqlSqlBaseWalker.whereClause(HqlSqlBaseWalker.java:776)
> 	at org.hibernate.hql.antlr.HqlSqlBaseWalker.updateStatement(HqlSqlBaseWalker.java:358)
> 	at org.hibernate.hql.antlr.HqlSqlBaseWalker.statement(HqlSqlBaseWalker.java:237)
> 	at org.hibernate.hql.ast.QueryTranslatorImpl.analyze(QueryTranslatorImpl.java:227)
> 	at org.hibernate.hql.ast.QueryTranslatorImpl.doCompile(QueryTranslatorImpl.java:159)
> 	at org.hibernate.hql.ast.QueryTranslatorImpl.compile(QueryTranslatorImpl.java:110)
> 	at org.hibernate.engine.query.HQLQueryPlan.<init>(HQLQueryPlan.java:77)
> 	at org.hibernate.engine.query.HQLQueryPlan.<init>(HQLQueryPlan.java:56)
> 	at org.hibernate.engine.query.QueryPlanCache.getHQLQueryPlan(QueryPlanCache.java:71)
> 	at org.hibernate.impl.AbstractSessionImpl.getHQLQueryPlan(AbstractSessionImpl.java:133)
> 	at org.hibernate.impl.AbstractSessionImpl.createQuery(AbstractSessionImpl.java:112)
> 	at org.hibernate.impl.SessionImpl.createQuery(SessionImpl.java:1586)
> 	at org.hibernate.ejb.AbstractEntityManagerImpl.createQuery(AbstractEntityManagerImpl.java:77)
> 	at org.dicr.isp.mbean.DataManager.deleteGroup(DataManager.java:121)
> 	at org.apache.jsp.admin.data.group_del_jsp._jspService(group_del_jsp.java:67)
> 	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:94)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:860)
> 	at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:329)
> 	... 17 more
> 194:  Type componentType = getNakedPropertyType(fromElement);
> 195:  if (!componentType.isComponentType()) {
> 196:        throw new QueryException("Property '" + getOriginalText() + "' is not a component.  Use an alias to reference associations or collections.");
> 197: }
> This occur if  EJB3-QL query contains this errors:
> update GroupDO set GroupDO._deleted = now() where GroupDO._id = ?1 and GroupDO._deleted is NULL
> Correct query work fine:
> update GroupDO set _deleted = now() where _id = ?1 and _deleted is NULL

-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HHH-1) Optimize Hibernate for the bulk insertion of related entities

[Christian B. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1?page=comments#action_23108 ] 

Christian Bauer commented on HHH-1:
-----------------------------------

Go to the forum, this has nothing to do with this case.


> Optimize Hibernate for the bulk insertion of related entities
> -------------------------------------------------------------
>
>          Key: HHH-1
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1
>      Project: Hibernate3
>         Type: New Feature

>   Components: core
>  Environment: Hibernate 1.2, MySql 3.1
>     Reporter: Bradley Leupen
>     Priority: Minor

>
>
> It is currently difficult to batch the creation of persistent entities that maintain associations with other entities.
> Add necessary api to hibernate to support the save or update of a collection of entities. An optimization can be applied in this scenario to group inserts / updates by entity class, or table. This will enable the hibernate engine to utilize batching if available, drastically improving performance over a network. 

-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira