[Hibernate-JIRA] Created: (HHH-2065) object primary key with increment option + hsqldb + multiple schemas
by jojo (JIRA)
object primary key with increment option + hsqldb + multiple schemas
--------------------------------------------------------------------
Key: HHH-2065
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2065
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.1.3
Environment: This bug was discovered using Hibernate 3.1.3 and hsqldb 1.8.0.1. It was also reproduced using hsqldb 1.8.0.5.
Reporter: jojo
How to reproduce the bug:
1. Use Hibernate 3.1.3 + hsqldb 1.8.0.x
2. Create an hsqldb database (file or memory) and create a table on a named schema (let's say MYSCHEMA.MYTABLE)
3. Map this table with a POJO+hibernate mapping file and setup its primary key id with "increment" option (of course don't forget to set schema name in your mapping).
4. Create an instance of this object without giving him an id and try to save it :
=> The problem appears when trying to get MAX(ID) of MYTABLE. Indeed, the schema name is not taken into account. The underlying sql request that should be : SELECT MAX(ID) FROM MYSCHEMA.MYTABLE, is SELECT MAX(ID) FROM MYTABLE which cause errors.
--
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] Created: (HHH-2092) Programmatic config and XML config react differently to the same propety names (when not prefaced with "hibernate")
by John Kaplan (JIRA)
Programmatic config and XML config react differently to the same propety names (when not prefaced with "hibernate")
-------------------------------------------------------------------------------------------------------------------
Key: HHH-2092
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2092
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.0.cr4
Environment: all
Reporter: John Kaplan
Priority: Minor
This is a usability problem with the Configuration api that surfaces when a user is trying programmatic configuration after using XML configuration. It is common usage that property names for XML configuration are not prefaced with "hibernate" (e.g. in the "getting started" tutorial). But for programmatic configuration, they are required to be prefaced. This violates a reasonable user expectation that similar interfaces should exhibit similar behavior when passed the same data.
If you try to use the property names from an XML config file in programmatic config, a variety of errors occur during session and transaction creation. These errors are difficult to troubleshoot for beginners, and it looks like programmatic config just doesn't work. Worse, if a user explicilty sets a hibernate property to its default through programmatic config (again following examples in "getting started") Hibernate behaves as expected, even though the user's intention failed and the hibernate property wasn't actually set. This sets a trap for the future failure of a change of that parameter's value which will be even harder to troubleshoot.
There is benefit to Hibernate support in fixing this, as users will no longer ask about errors rooted in this problem, and it will in a small way make Hibernate easier to learn.
The problem is a 2-line "if" block that was added to Configuration.addProperties() that is not reused in Configuration.setProperty(). The conditional of this statement checks if a property starts with "hibernate." and if it does not, it adds a copy of the parameter with the original name, and an extra copy of the parameter with the name prefaced with "hibernate.".
This is technically a snap to fix, but deciding on the right fix is the non-trivial part.
The most obvious fix is to move the 2-line "if" block to the Configuration.setProperty() method, and call that as a subroutine from its current place in Configuration.addProperties(). There are two upsides to this. First, the user's expectation of similar interfaces behaving the same is fuliflled in the most direct way, so the problem simply goes away with no explanations needed. Second, since this change is an addition, it should be completely backward-compatible for all but the most implementation-brittle tests.
The downside to this solution is that though it is a backward-compatible behavior change, it still is a behavior change. Anyone aware of the current implementation of Configuration.setProperty() that is taking advantage of the fact that it WON'T add an additional hibernate-rooted property loses that differentiation. However, it is hard to conceive that anyone would want to make sure programmatic configuration did NOT add an extra "hibernate"-rooted parameter knowing that's exactly what XML configuration WILL do. This means someone created a parameter with a similar name to a Hibernate parameter, and they know they can only set it programmatically, and are OK with the idea that anyone who tries to set it with XML will screw it up.
Next possible fix is to create a new Configuration.setHibernateProperty() method that acts the same as Configuration.addProperties(), and keep Configuration.setProperty() the way it is. This makes sure there is no behavior change of current Hibernate code whatsoever. Another upside is that even the most rudimentary javadoc of the two versions of setProperty() is sure to make the behavior obvious to users, and so much reduces the chance of any further misunderstanding (at least among the subset of users who read the javadoc). The downside is that this adds another API method. If the API is frozen by a standards body or in some similar process, this is likely a pain - you know more than I.
Next down the line is keep the behavior the same but doc it. When I ran into this, I checked the javadoc and the chapter in the online doc about programmatic config. It would have saved me frustration and time hacking if something had said explicitly, "When you use programmatic config, you have to preface properties with 'hibernate.'. This is different than XML config where you don't." I think this is more of a band-aid over the interface design problem, but it's better than nothing.
Discussion of this issue, with me complaining and offering fixes, and the wily Max gallantly defending the status quo is at:
http://forum.hibernate.org/viewtopic.php?p=2322023#2322023
--
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] Created: (HHH-2091) Adding mappings to Configuration before FilterDefinition leads to NullPointerException
by Josh Moore (JIRA)
Adding mappings to Configuration before FilterDefinition leads to NullPointerException
--------------------------------------------------------------------------------------
Key: HHH-2091
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2091
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.0.cr4
Environment: Hibernate 3.2.cr4 (r10506)
Java 5
Reporter: Josh Moore
Attachments: hbmbindertest.zip
The exception below is thrown when a mapping file contains a reference to a filter which is not in that or another mapping file. The call to addFilterDefinition must be done first.
<code>
public class HbmBinderTest extends TestCase
{
// This throws a NPE unless the filter definition is included.
protected void addMappings(String[] files, Configuration cfg) {
// cfg.addFilterDefinition( new FilterDefinition(
// "securityFilter","true",new HashMap()) );
super.addMappings(files, cfg);
}
</code>
java.lang.NullPointerException
at org.hibernate.cfg.HbmBinder.parseFilter(HbmBinder.java:2935)
at org.hibernate.cfg.HbmBinder.createClassProperties(HbmBinder.java:2110)
at org.hibernate.cfg.HbmBinder.createClassProperties(HbmBinder.java:2031)
at org.hibernate.cfg.HbmBinder.bindRootPersistentClassCommonValues(HbmBinder.java:359)
at org.hibernate.cfg.HbmBinder.bindRootClass(HbmBinder.java:273)
at org.hibernate.cfg.HbmBinder.bindRoot(HbmBinder.java:144)
at org.hibernate.cfg.Configuration.add(Configuration.java:424)
at org.hibernate.cfg.Configuration.addInputStream(Configuration.java:465)
at org.hibernate.cfg.Configuration.addResource(Configuration.java:494)
at org.hibernate.test.TestCase.addMappings(TestCase.java:230)
at org.hibernate.test.TestCase.buildSessionFactory(TestCase.java:180)
at org.hibernate.test.TestCase.setUp(TestCase.java:157)
--
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-1685) DetachedCriteria doesn't create alias on subcriteria
by Jorge L. Middleton (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1685?page=c... ]
Jorge L. Middleton commented on HHH-1685:
-----------------------------------------
The method createAlias return this, not the new subcriteria created by criteria.createAlias(associationPath, alias);
Is this correct??
> DetachedCriteria doesn't create alias on subcriteria
> ----------------------------------------------------
>
> Key: HHH-1685
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1685
> Project: Hibernate3
> Type: Bug
> Components: query-criteria
> Versions: 3.1.3
> Reporter: John
> Attachments: hhh1685-example.txt
>
>
> DetachedCriteria has two createCriteria methods:
> public DetachedCriteria createCriteria(String associationPath) throws HibernateException
> public DetachedCriteria createCriteria(String associationPath, String alias) throws HibernateException
> However, the code for both was identical - they called the inner criteria's createCriteria(String) method. The version with the alias did not call the inner's version with the alias. The following patch snipped shows the change:
> public DetachedCriteria createCriteria(String associationPath, String alias)
> throws HibernateException {
> - return new DetachedCriteria( impl, criteria.createCriteria(associationPath) );
> + return new DetachedCriteria( impl, criteria.createCriteria(associationPath, alias) );
> }
> This bug was discovered while trying to link a 2-deep subquery to its parent via aliases. (Surfacing this issue might only be possible with the patch HHH-952 in place - I'm not sure. Seems like a bug regardless, as it definitely fixed my alias reference issue.) I'll get an example posted shortly.
--
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) using projections is causing SQL query error on oracle (ORA-00904 error)
by Max Rydahl Andersen (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-817?page=co... ]
Max Rydahl Andersen commented on HHH-817:
-----------------------------------------
workaround have been posted (by francois) and feel free to submit a patch that fixes it.
> using projections is causing SQL query error on oracle (ORA-00904 error)
> ------------------------------------------------------------------------
>
> Key: HHH-817
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-817
> Project: Hibernate3
> Type: Bug
> 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
>
>
> 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] Commented: (HHH-817) using projections is causing SQL query error on oracle (ORA-00904 error)
by Vetlugin Yury (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-817?page=co... ]
Vetlugin Yury commented on HHH-817:
-----------------------------------
Still no support from Oracle or MySQL (Oracle 10g, mysql 5.0.13rc, hibernate 3.0.5). It`s real pain in ass.
> using projections is causing SQL query error on oracle (ORA-00904 error)
> ------------------------------------------------------------------------
>
> Key: HHH-817
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-817
> Project: Hibernate3
> Type: Bug
> 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
>
>
> 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