[Hibernate-JIRA] Commented: (HHH-1742) SQL join is missed in Criteria queries for join/alias on foreign key as part of composite primary key (many-to-one association)
by Mattias Jiderhamn (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1742?page=c... ]
Mattias Jiderhamn commented on HHH-1742:
----------------------------------------
After a bit of debugging it seems the problem lies within the JoinWalker (or specifically CriteriaJoinWalker). When creating a list of associations that may be used for joins (in walkEntityTree()) it only looks at the properties of the persister/OuterJoinLoadable (SingleTableEntityPersister in my case). The composite-id/key-many-to-one mappings are not listed as properties, and therefore not even considered for joins. So, when AbstractEntityJoinWalker creates the actual statement, it doesn't know about the relation to the "parent" (key-many-to-one).
Not sure yet what the correct change would be, but hopefully somebody could use the information above or I find the time to try something out.
> SQL join is missed in Criteria queries for join/alias on foreign key as part of composite primary key (many-to-one association)
> -------------------------------------------------------------------------------------------------------------------------------
>
> Key: HHH-1742
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1742
> Project: Hibernate3
> Type: Bug
> Components: query-criteria
> Versions: 3.2.0 cr1
> Environment: Windows XP, Oracle 10g, HSQLDB
> Reporter: Viatcheslav Sysoltsev (Slavka)
> Attachments: HibernateTest.zip
>
>
> I've stuck with Criteria API on issue, that the join is sometimes missed from generated SQL query doing joining on foreign key.
> Here is the little example I've made to demonstrate the problem (also attached as standalone runnable eclipse project)
> There are two tables:
> FAMILY
> familyName as primary key
> familyProperty
> PERSON
> familyName as foreign key on FAMILY } the both fields make primary key
> personName } of PERSON
> Doing query on person like
> session.createCriteria(Person.class)
> .createCriteria("id.family")
> .add(Restrictions.eq("familyProperty", "whatever"))
> .list();
> Causes query
> Hibernate: select this_.FAMILY_NAME as FAMILY1_1_0_, this_.PERSON_NAME as PERSON2_1_0_ from PERSON this_ where family1_.FAMILY_PROPERTY=?
> .. which is rather invalid
> The same by the way happens doing query
> session.createCriteria(Person.class)
> .createCriteria("id.family")
> .add(Restrictions.eq("familyName", "whatever"))
> .list();
> The query
> select this_.FAMILY_NAME as FAMILY1_1_0_, this_.PERSON_NAME as PERSON2_1_0_ from PERSON this_ where family1_.FAMILY_NAME=?
> .. is invalid either though it can be made valid without join, because family1_.FAMILY_NAME can be accessed through this_.FAMILY_NAME
> The attachment is a whole eclipse project, pretty straightforward, with hsqldb, which demonstrates the SQL generated and the problem.
> I suspect this bug may be caused by the fix to HH-528 (component.manyToOne.id in HQL causes join).
> The priority should be high because
> session.createCriteria(Person.class)
> .createAlias("id.family", "family")
> .add(Restrictions.eq("family.familyProperty", "whatever"))
> .list();
> doesn't work either.
> In effect there is no way to cause join on foreign key with Criteria API. Whatever in hibernate blocks join on foreign key rather zealous.
--
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
19 years
[Hibernate-JIRA] Created: (ANN-448) @OrderBy does not work with an association table when Set is used for collection
by Mike Wilson (JIRA)
@OrderBy does not work with an association table when Set is used for collection
--------------------------------------------------------------------------------
Key: ANN-448
URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-448
Project: Hibernate Annotations
Type: Bug
Versions: 3.2.0.cr2
Environment: Hibernate 3.2CR4, Oracle 10
Reporter: Mike Wilson
Attachments: patch.txt
We are using Set for our mapped collections, and not Collection like in the unit tests for annotations. We can see that the items are inserted in the Set according to the order governed by @OrderBy, but apparently Hibernate is not using an order-preserving Set like f ex LinkedHashSet.
We were under the impression that Hibernate would support ordered Sets by using a suitable (ordered) Set subclass when an @OrderBy is specified and this is confirmed by Emmanuel on http://forum.hibernate.org/viewtopic.php?p=2324711.
I supply a patch file that adds a new test case to the annotations "ManyToMany" test:
GroupWithSet.java:
- property "permissions" as Set instead of Collection
ManyToManyTest.java:
- new method "testAssociationTableAndOrderByWithSet()" with:
. using GroupWithSet
. added an extra permission + check order of all three perms to avoid the 50% chance of random order being correct
(And I have tested by running against CVS HEAD version)
Best regards
Mike Wilson
--
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
19 years
[Hibernate-JIRA] Created: (HHH-2273) AnnotationConfiguration generateSchemaCreationScript OneToMany constraints problem
by Milan Pecko (JIRA)
AnnotationConfiguration generateSchemaCreationScript OneToMany constraints problem
----------------------------------------------------------------------------------
Key: HHH-2273
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2273
Project: Hibernate3
Type: Bug
Versions: 3.2.0.ga
Environment: Windows XP,
Sun java 1.5.0-06
MSSQL
Reporter: Milan Pecko
There is a base class TBase. T1 and T2 extends from TBase (InheritanceType.JOINED) (and many others too),
T1 and T2 has a collection references to TRef, TRef references TBase,
see below for short class definition.
schema creation produces constraints :
alter table T_REF_TBL add constraint con_1_ foreign key (refId) references T_BASE_TBL
alter table T_REF_TBL add constraint con_2_ foreign key (refId) references T_1_TBL
alter table T_REF_TBL add constraint con_2_ foreign key (refId) references T_2_TBL
so there is no posibility to store T1 or T2 due constraint violation exception.
I have tried to use middleclass TBaseWithSet (annotated as @MappedSuperclass) with collection but the same constraints was created.
Shor class definition:
@Entity
@Inheritance(strategy = InheritanceType.JOINED)
@Table(name = "T_BASE_TBL")
public class TBase implements java.io.Serializable {
@Id
@GeneratedValue(strategy = GenerationType.AUTO)
public Long getId() {
...
}
........
}
@Entity
@javax.persistence.Table(name = "T_REF_TBL")
@ExcomWeb(urn = "Excom2:InstrumentInterestRateEntry")
public class TRef implements java.io.Serializable {
@Id
@GeneratedValue(strategy = GenerationType.AUTO)
public Long getId() {
...
}
@ManyToOne(fetch = FetchType.LAZY)
@JoinColumn(name = "refId")
public TBase getBase() {
....;
}
........
}
@Entity
@PrimaryKeyJoinColumn(name = "id")
@Table(name = "T1_TBL")
public class T1 extends TBase implements java.io.Serializable {
@OneToMany(targetEntity = TRef.class, mappedBy = "refId" fetch = FetchType.LAZY)
@Cascade( {org.hibernate.annotations.CascadeType.ALL, org.hibernate.annotations.CascadeType.DELETE_ORPHAN} )
public Set getReferencies() {
...
}
...........
}
@Entity
@PrimaryKeyJoinColumn(name = "id")
@Table(name = "T2_TBL")
public class T2 extends TBase implements java.io.Serializable {
@OneToMany(targetEntity = TRef.class, mappedBy = "refId" fetch = FetchType.LAZY)
@Cascade( {org.hibernate.annotations.CascadeType.ALL, org.hibernate.annotations.CascadeType.DELETE_ORPHAN} )
public Set getReferencies() {
...
}
...........
}
schema export :
...
alter table T_REF_TBL add constraint con_1_ foreign key (refId) references T_BASE_TBL
alter table T_REF_TBL add constraint con_2_ foreign key (refId) references T_1_TBL
alter table T_REF_TBL add constraint con_2_ foreign key (refId) references T_2_TBL
...
--
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
19 years
[Hibernate-JIRA] Commented: (HHH-1476) Table.qualify does not handle dialect diferences
by Stefaan Van Mieghem (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1476?page=c... ]
Stefaan Van Mieghem commented on HHH-1476:
------------------------------------------
You can add this case:
Informix database:owner.table
catalog separator = ':' (colon)
schema separator = '.' (dot)
Using table="<database>:<table>" in the mapping works, but binds your hibernate mapping to a specific database.
> Table.qualify does not handle dialect diferences
> ------------------------------------------------
>
> Key: HHH-1476
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1476
> Project: Hibernate3
> Type: Bug
> Components: core
> Environment: Hibernate 3.1.2
> SQL Server 2000
> Reporter: Justin Kolb
>
>
> The fix for HHH-699 caused me to discover that Hibernate isn't handling qualifying table names properly. It can be inferred from HHH-699 that not all databases are similar in this respect so I think this should be added to the dialect handling. From my short research I have the following 3 cases:
> SQL Server: database.owner.table
> MySQL: database.table (no schemas it seems)
> Most others: catalog.schema.table
> SQL Server also allows for "database..table" since it does not have schemas but does allow you to write queries that cross databases similar to how you can cross schemas in other database servers.
> Testing on Postgres though I determined that it does not allow "catalog..table" and will only accept "catalog.schema.table", so it dos not match up with SQL Server in this respect. If you write "catalog.table" it thinks you are trying to use a schema so it does not match up with MySQL in this respect.
> So right now only MySQL and SQL Server are the non standard compliant databases. Before 3.1 beta 1, SQL Server was handled correctly; then after that only MySQL was handled correctly.
> I'm not sure how much work it would take to make this change.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
19 years
[Hibernate-JIRA] Updated: (HHH-1612) Serious performance lost within IdentityMap...
by Markus Heiden (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1612?page=all ]
Markus Heiden updated HHH-1612:
-------------------------------
Attachment: hack.zip
This are patched classes based on hibernate 3.2.0 ga. This patch is a hack, because it just fits for this particular problem and is designed for minimal source code changes. This patch reduces the amount of time consumed by cascading saves of transient objects, but does not fix HHH-2272.
> Serious performance lost within IdentityMap...
> ----------------------------------------------
>
> Key: HHH-1612
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1612
> Project: Hibernate3
> Type: Improvement
> Components: core
> Versions: 3.1.3
> Reporter: Peter Fassev
> Priority: Critical
> Attachments: Hibernate_3.1.3_performance.jpg, hack.zip
>
>
> Please look at the attached profiler snapshot.
> After I switched from 3.0.5 to 3.1.3 I have mentioned a serious performance decrease when perfecting data, especially on loading non lazy collection (for instance Arrays of String[]). A simple fetch query, which was executed in 6 seconds on hibernate 3.0.5, now it takes 40 seconds on 3.1.3 (without any changes to the application). The fetch of the whole data needs with 3.1.3 about 90 seconds, with 3.0.5 about 49, which is a serious performance lost.
> The NetBeans Profiler shows a huge increase of the self time of the IdentityMap.entrySet() method. Now it takes 22,3% of the whole start time. Together with it's calling method BatchFetchQueue.getCollectionBatch() it consumes 36 % of the start time, which explains the performance lost pretty good.
> Looking at the source code I saw that there is already a TO DO regarding the performance of the IdentityMap.entrySet(), so please fix it, if possible. I think the whole implementation of the IdentityMap should be rethinked, because currently only a dirty hack is possible. If you can't use the IdentityHashMap of 1.4 due to compatibility reasons, please take a look at the current release of apache commons-collections (3.1), where you will find an IdentityHashMap.
> With best regards
> Peter
--
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
19 years
[Hibernate-JIRA] Commented: (HHH-1) Optimize Hibernate for the bulk insertion of related entities
by Michael Kopp (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1?page=comm... ]
Michael Kopp commented on HHH-1:
--------------------------------
1) well in case of a merge sort you are right. I didn't think about that. But would traversing really be faster than a bubble sort in this case? i'm not sure about that.
But you are wrong that we need to consider hibernate entities. we need to consider EntityInsertActions. the state contains only what is to be inserted.
so 3) is a mute point because of that. if it is inverse there would be two insert actions where one state would refer the other, if it was not inverse there would still be two insert actions, but none would refer the other. the referral would be added by an UpdateAction.
The following traversal would be possible.
- first build up a java.util.IdentityHashMap: EntityAction.instance --> EntityInsertAction
and make that Map available to the to the InsertAction
this can be done before calling the sort itself.
in the compare:
final EntityInsertAction entityInsertAction = ((EntityInsertAction) other);
final Object instance = entityInsertAction.getInstance();
if (instance != getInstance())
{
// if any of our properties is actually to be inserted, it has to be before us
int relation=0;
for (int i = 0; i < state.length; i++)
{
final Object rel = state[i];
if (rel == instance)
{
relation +=1; // the 'other' InsertAction inserts something that we need. it has to be before us in the queue
}else
{
EntityInsertAction related = insertActionMap.get(rel);
if (related != null) // we found a relation to another object. that must be definitely before us. lets see if other is a parent of related and thus a parent of us
{
relation += related.compareTo(entityInsertAction);
}
}
}
and the same for the other way around. I haven't completely thought it through but I think this would work out.
- One thing to take care of is an endless loop here due to bidirectional 1-1 relations
- One other thing I hadn't considered are inverse unidirectional relations where only the parent has a relation to the child (collection). This would not be correctly handled at the moment. In this case one would have to check for collections too.
> 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....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
19 years