July 2011 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HSEARCH-771) ProgrammaticMappingTest should work when executed in any order

by Sanne Grinovero (JIRA)

ProgrammaticMappingTest should work when executed in any order -------------------------------------------------------------- Key: HSEARCH-771 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-771 Project: Hibernate Search Issue Type: Task Components: tests Reporter: Sanne Grinovero Assignee: Sanne Grinovero Priority: Trivial Fix For: 4.0.0.Alpha1 testNumeric is not cleaning up the data it stores, this affects other test methods; was hard to spot as it's not reproduced as testNumeric happens to be the last test executed from commandline or from any IDE, but it happens to be executed in a different order on CI. -- 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

14 years, 8 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-769) dummy is a reserved keyword on sybase

by Sanne Grinovero (JIRA)

dummy is a reserved keyword on sybase ------------------------------------- Key: HSEARCH-769 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-769 Project: Hibernate Search Issue Type: Task Reporter: Sanne Grinovero Assignee: Sanne Grinovero Priority: Trivial Fix For: 4.0.0.Alpha1 As it's used as property name in some tests, these are failing when run on Sybase. -- 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

14 years, 8 months

1
2
0 / 0

[Hibernate-JIRA] Created: (OGM-69) Introduce a Tuple object instead of Map<String, Object> and the equivalent for the association info

by Emmanuel Bernard (JIRA)

Introduce a Tuple object instead of Map<String,Object> and the equivalent for the association info -------------------------------------------------------------------------------------------------- Key: OGM-69 URL: http://opensource.atlassian.com/projects/hibernate/browse/OGM-69 Project: Hibernate OGM Issue Type: Improvement Reporter: Emmanuel Bernard sanne other thing, you keep passing around "tuples", i.e. "Map<String, Object>" . wouldn't it be nice to make our object for that? I know we discussed it about the keys, but for objects we where unsure, depending on how it's looking in the end. but it looks like to make sense to me now.. emmanuel yes indeed, my train of thoughts is the following we will replace Cache with our own object (see Bucket discussion) and yes I think having a Tuple object would make sense as wll (same of the association info potentially Tuple and thw Association info one would record the list of changes applied (ie add / update / remove such and such column) And from this set of information the Dialect will be able to store the data accordingly 15:11 In ISPN via an AtomicMap for example I'm a little bit concerned about the overhead of creating and maintaining two sets of object in the end the Tuple and what ISPN or other dialect end up having but that might not be too problematic sannegrinovero: but I'd keep this enhancement for a different JIRA / pull-request -- 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

14 years, 8 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HHH-6490) Support @javax.persistence.Lob

by Hardy Ferentschik (JIRA)

Support @javax.persistence.Lob ------------------------------ Key: HHH-6490 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6490 Project: Hibernate Core Issue Type: Sub-task Reporter: Hardy Ferentschik -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 8 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-6506) Descriminator type is not resolved

by Gail Badner (JIRA)

Descriminator type is not resolved ---------------------------------- Key: HHH-6506 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6506 Project: Hibernate Core Issue Type: Bug Components: metamodel Reporter: Gail Badner Assignee: Gail Badner Fix For: 4.0.0.next -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 8 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HHH-6519) Temporarily set default column precision, scale, and length

by Gail Badner (JIRA)

Temporarily set default column precision, scale, and length ----------------------------------------------------------- Key: HHH-6519 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6519 Project: Hibernate Core Issue Type: Task Components: metamodel Reporter: Gail Badner Assignee: Gail Badner Fix For: 4.0.0.next Until HHH-6045 is fixed, defaults for column precision, scale, and length needs to be set in org.hibernate.metamodel.relational.Size so that SchemaExport can succeed. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 8 months

1
2
0 / 0

[Hibernate-JIRA] Created: (HHH-3305) hbm2ddl: MS SQL Server 2005 defaults to Clustered Index on PK, lets use PRIMARY KEY NONCLUSTERED for hbm2ddl as a more reasonable default

by Jim Doyle (JIRA)

hbm2ddl: MS SQL Server 2005 defaults to Clustered Index on PK, lets use PRIMARY KEY NONCLUSTERED for hbm2ddl as a more reasonable default ------------------------------------------------------------------------------------------------------------------------------------------- Key: HHH-3305 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3305 Project: Hibernate3 Issue Type: Bug Components: metamodel Affects Versions: 3.2.1 Reporter: Jim Doyle In SQL Server 2005, PRIMARY KEY defaults to creating a Clustered Index for the PK column at table creation time. To confirm this behaviour Please see: http://msdn.microsoft.com/en-us/library/ms188066.aspx This default behaviour is un-desireable for a number of reasons: 1. No other databases default to a clustered IDX at the PK ; Not DB2, nor Oracle nor MySQL 2. There may only be ONE clustered IDX per table. By using this as a default makes it difficult for the app developer or DBA to quickly add or change the once-per-table opportunity to use the cluster to improve query performance. 3. The default cluster index that Microsoft applies seems only to benefit naive SQL server users with little to no DBA skills. Table insert of new rows onto a Clustered Index PK is always very fast and while this optimization may be impressive if your problem space is rapidly inserting new data into large tables, this optimization is often an antipattern to users with more plausible query patterns such as scan by non-primary key date, numeric amounts or alphabetical data. 4. Defaulting the PK to clustered creates SUBSTANTIAL burden for a DBA when the Clustered Index needs to be removed from the PK to be deployed on other columns on the table. As an example of the burden that this creates, for EACH TABLE one must: - Discover all tables and columns that link back to the table in question through FOREIGN KEY - Drop all foreign keys - Drop the PK - Add the PK back, with NONCLUSTERED - Put back all the dropped Foreign keys 5. Additional arguments against supporting Microsoft's unusual default is given here: http://tonesdotnetblog.wordpress.com/2008/05/26/twelve-tips-for-optimisin... (Please See Section 2: Use Clustered Index). I propose ANY ONE of the following enhancements to the DDL generator for the SQL Server 2005 Dialect: 1. Change the generated SQL from colname coltype PRIMARY KEY TO colname coltype PRIMARY KEY NONCLUSTERED such that PK index generate conforms the the usual, sensible defaults of other database products. 2. Use a Properties attribute (i.e. hibernate.hbm2ddl.dialect.mssql.use_non_clustered_pk) that is evaluated at hbm2ddl runtime that will emit 'NONCLUSTERED' to the PK clause. If this Property is not defined, the hbm2ddl will simply emit PRIMARY KEY as it does now and MS SQL Server will use its peculiar and annoying default. -- 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

14 years, 8 months

3
2
0 / 0

[Hibernate-JIRA] Created: (HHH-6518) Request malformed on a left fetch join subItem.myCollection (double outer join) : uncorrect fromElementList, can't find the associated collectionOwner and initialize a proxy on an empty fetched collection

by Quentin Ambard (JIRA)

Request malformed on a left fetch join subItem.myCollection (double outer join) : uncorrect fromElementList, can't find the associated collectionOwner and initialize a proxy on an empty fetched collection ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Key: HHH-6518 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6518 Project: Hibernate Core Issue Type: Bug Components: core, query-sql Affects Versions: 4.0.0.Beta4, 3.6.6 Reporter: Quentin Ambard Attachments: hibernateTestCase.tar.gz There is an error fetching a collection of a subitem. This affect empty collections : a proxy is intialized on the collection, even fetched. Accessing to this collection fire a new request. Here is a simple mode. Please see test case for complete implementation: @Entity @Table( name = "ITEM" ) public class Item { @Id @GeneratedValue private Long id; @OneToOne(cascade = { CascadeType.ALL }, optional = true, fetch = FetchType.LAZY, orphanRemoval = true) @JoinColumn(name = "SUB_ITEM_ID") private SubItem subItem ; ... } public class SubItem { @Id @GeneratedValue private Long id; @ElementCollection(targetClass = String.class, fetch = FetchType.LAZY) @CollectionTable(name = "PHONES") @Column(name = "PHONE", nullable = false) private List<String> phones ; ... } the following hql request "from Item i left join fetch i.subItem left join fetch i.subItem.phones" generates this sql request : select item0_.id as id2_0_, subitem1_.id as id1_1_, item0_.SUB_ITEM_ID as SUB2_2_0_, phones3_.SubItem_id as SubItem1_1_0__, phones3_.PHONE as PHONE0__, phones3_.SubItem_id as SubItem1_1_0__, phones3_.PHONE as PHONE0__ from ITEM item0_ left outer join SUB_ITEM subitem1_ on item0_.SUB_ITEM_ID=subitem1_.id left outer join SUB_ITEM subitem2_ on item0_.SUB_ITEM_ID=subitem2_.id left outer join PHONES phones3_ on subitem2_.id=phones3_.SubItem_id There is an extra left outerjoin. QueryClassLoader.initialize(SelectClause selectClause) can't find the collectionOwner for the PHONES collection : collectionFromElement.getOrigin()is about the second left outer join : "SUB_ITEM subitem2_ on item0_.SUB_ITEM_ID=subitem2_.id" and the fromElementList is based on the first outer join "subitem1_ on item0_.SUB_ITEM_ID=subitem1_.id". The following hql request doesn't work either : from Item i left join fetch i.subItem s left join fetch s.phones Request is correctly generated, but the left outer join collectionPersisters is null java.lang.NullPointerException at org.hibernate.loader.BasicLoader.isBag(BasicLoader.java:97) at org.hibernate.loader.BasicLoader.postInstantiate(BasicLoader.java:76) at org.hibernate.loader.hql.QueryLoader.<init>(QueryLoader.java:120) at org.hibernate.hql.internal.ast.QueryTranslatorImpl.doCompile(QueryTranslatorImpl.java:204) ... see attached test case for full stack -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 8 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-819) Performance and Integration tests still using HSQLDB (project uses H2)

by Sanne Grinovero (JIRA)

Performance and Integration tests still using HSQLDB (project uses H2) ---------------------------------------------------------------------- Key: HSEARCH-819 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-819 Project: Hibernate Search Issue Type: Bug Components: tests Reporter: Sanne Grinovero Assignee: Sanne Grinovero Priority: Minor Fix For: 4.0.0.Alpha1 These tests are not run automatically, and are currently broken as HSQLDB is not on the classpath since we moved to H2. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 8 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-760) ReaderProvider to not provide MultiSearchers

by Sanne Grinovero (JIRA)

ReaderProvider to not provide MultiSearchers -------------------------------------------- Key: HSEARCH-760 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-760 Project: Hibernate Search Issue Type: Task Reporter: Sanne Grinovero Fix For: 4.0.0.Alpha1 We still need to provide MultiSearchers, but this should do this at another level: the ReaderProvider interface needs to be coupled to the IndexManager ( see also HSEARCH-758 ) and thus be coupled to a single index. -- 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

14 years, 8 months

1
2
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues July 2011