[Hibernate-JIRA] Commented: (HHH-1233) Allow mixing <union-subclass>and <subclass>
by James Carman (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1233?page=c... ]
James Carman commented on HHH-1233:
-----------------------------------
This would be a VERY nice feature. We had an existing schema that we had to split out into individual tables because this wasn't implemented yet. Please implement this.
> Allow mixing <union-subclass>and <subclass>
> -------------------------------------------
>
> Key: HHH-1233
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1233
> Project: Hibernate3
> Issue Type: Improvement
> Components: core
> Environment: N/A
> Reporter: Gunther Schadow
>
> BACKGROUND:
> Hibernate allows mixing <subclass> and <joined-subclass> inheritance mappings but apparently not <subclass> and <union-subclass> mappings, however, this seems like the most useful combination. Example:
> USE CASE:
> We may have a hierarchy with very unevenly distributed mass, i.e., some subclasses have millions of objects, others have only a half-dozen. There may be a lot of different subclasses of the smaller sort.
> Union-subclass seems ideal to work with a dozen different humongous tables, as they can be placed on different tablespaces and managed differently. However, for the 200 or so subclasses whith only a dozen objects each, it would be easier to map these into a single table per sub-hierarchy.
> REQUESTED FEATURE:
> Therefore it seems fair to suggest that <subclass> mappings should be supported underneath <union-subclass> mappings. To allow that the <discriminator> element would have to be handled inside a <union-subclass> element and same for the discriminator-value attribute. Perhaps one could limit the complexity by requiring that the outer mapping must be union-subclass and the inner can be subclass but not vica versa?
> WORKAROUNDS:
> As the documentation mentions one could just create several independent <class> hierarchies, thus effectively emulating the first level of union-subclass specializations. But that would not allow specifying polymorphic associations.
> ESTIMATED EFFORT:
> It could be difficult to implement support for this. But would like to know whether this is something that is somewhere on the radar screen for the future.
--
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
16 years, 10 months
[Hibernate-JIRA] Closed: (HBX-688) hbm2java is not generating the @Version annotation for the <version ...> element
by Max Rydahl Andersen (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-688?page=co... ]
Max Rydahl Andersen closed HBX-688.
-----------------------------------
Resolution: Duplicate
> hbm2java is not generating the @Version annotation for the <version ...> element
> --------------------------------------------------------------------------------
>
> Key: HBX-688
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-688
> Project: Hibernate Tools
> Issue Type: Bug
> Components: hbm2java
> Affects Versions: 3.1.beta5
> Reporter: Sean Dawson
> Attachments: BasicPOJOClass.patch
>
>
> See http://forum.hibernate.org/viewtopic.php?p=2310547#2310547
> Given a mapping file:
> ----
> <?xml version="1.0"?>
> <!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN"
> "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
> <!-- Generated Jun 13, 2006 3:27:21 PM by Hibernate Tools 3.1.0.beta5 -->
> <hibernate-mapping>
> <class name="Sample" table="Sample">
> <id name="id" type="java.lang.Long">
> <column name="id" />
> <generator class="native" />
> </id>
> <version name="version" column="version"/>
> <property name="value" column="value" type="string"/>
> </class>
> </hibernate-mapping>
> ----
> the following ejb is generated (via hbm2java, ejb3="true", jdk5="true":
> ----
> // default package
> // Generated Jun 16, 2006 3:23:35 PM by Hibernate Tools 3.1.0.beta5
> import javax.persistence.Column;
> import javax.persistence.Entity;
> import javax.persistence.GeneratedValue;
> import javax.persistence.Id;
> import javax.persistence.Table;
> /**
> * Sample generated by hbm2java
> */
> @Entity
> @Table(name="Sample"
> )
> public class Sample implements java.io.Serializable {
> // Fields
> private Long id;
> private Integer version;
> private String value;
> // Constructors
> /** default constructor */
> public Sample() {
> }
> /** full constructor */
> public Sample(String value) {
> this.value = value;
> }
>
>
> // Property accessors
> @Id @GeneratedValue
>
> @Column(name="id", unique=false, nullable=false, insertable=true, updatable=true)
> public Long getId() {
> return this.id;
> }
>
> public void setId(Long id) {
> this.id = id;
> }
>
> @Column(name="version", unique=false, nullable=false, insertable=true, updatable=true)
> public Integer getVersion() {
> return this.version;
> }
>
> public void setVersion(Integer version) {
> this.version = version;
> }
>
> @Column(name="value", unique=false, nullable=true, insertable=true, updatable=true)
> public String getValue() {
> return this.value;
> }
>
> public void setValue(String value) {
> this.value = value;
> }
> }
> -----
> There should be a @Version annotation on the version property!
--
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
16 years, 10 months
[Hibernate-JIRA] Assigned: (HHH-952) Patch to allow subqueries with joins using Criteria API and Subqueries with DetachedCriteria
by Chris Bredesen (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-952?page=co... ]
Chris Bredesen reassigned HHH-952:
----------------------------------
Assignee: Chris Bredesen
> Patch to allow subqueries with joins using Criteria API and Subqueries with DetachedCriteria
> --------------------------------------------------------------------------------------------
>
> Key: HHH-952
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-952
> Project: Hibernate3
> Issue Type: Patch
> Components: core
> Affects Versions: 3.1 beta 1, 3.1 beta 2
> Environment: 3.1beta1 with MS SQL 2000 via jTDS
> Reporter: John
> Assignee: Chris Bredesen
> Priority: Critical
> Attachments: subquery-patch-3.2.4.SP1.txt, subquery-patch-311.txt, subquery-patch-313.txt, subquery-patch-31beta3.txt, subquery-patch.txt, subquery-patch.txt, SubqueryExpression.java
>
>
> The existing code in SubqueryExpression.java constructed a select statement but did not have any provisions for creating joins. Therefore, it was not possible using the criteria API to create an exists subselect that had a join, even though running the source DetachedCriteria alone works perfectly.
> For example, if this is the goal:
> select * from foo f
> where exists (select id from bar b join other o on b.o_id = o.id where o.prop = '123' and b.foo_id = f.id)
> One might try something like this:
> Criteria crit = session.createCriteria(Foo.class, fooAlias);
> DetachedCriteria barCrit = DetachedCriteria.forClass(Bar.class, barAlias);
> DetachedCriteria otherCrit = barCrit.createCriteria(Bar.OTHER_JOIN);
> otherCrit.add( Restrictions.eq(Other.PROP, "123") );
> barCrit.add( Restrictions.eqProperty( -- props to join to foo here --) );
> barCrit.setProjection( Projections.id() );
> crit.add( Subqueries.exists(barCrit) );
> However, the existing code generates something like the following, which gets an error with an unknown alias 'o':
> select * from foo f
> where exists (select id from bar b where o.prop = '123' and b.foo_id = f.id)
> This is also described here (at the end): http://forum.hibernate.org/viewtopic.php?t=942488
> The patch to SubqueryExpression.java fixes this to included the joins necessary for the filtering. This code was modeled (copied) off of code from CriteriaLoader. For me this works perfectly, but I don't understand the internals of this stuff enough to say how robust it is. Also included is a patch to the test case to enable testing of this, which was present but commented out. I did not change the contents of the test, which currently only attempts a joined subquery. This used to fail with an error, but now it works. The test does not check the results at all. (Inconsequential to the patch - Enrollment has two Ls.)
> -----side notes
> The patch file also has two other patches. The first increases the delay in BulkManipulationTest because I was getting inconsistent test results. I think that the precision on the version timestamp is not enough for 300 milliseconds delay to be enough to guarantee the test results. Also, in build.xml, there was a line that was meant to exclude the performance tests, but there was no **/*, on *, so they actually were not excluded. I changed this so the tests would complete in a reasonable amount of time. However, there is one other issue with testing that I worked around manually. After each test run, two databases (Users and Email) were left in the database. If I did not manually delete these then the number of failures on the next test run was different. This was really confusing until I figured it out because I was trying to make sure all the other testcases still passed with my patch, but even without the patch I was getting different results.
--
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
16 years, 11 months