June 2009 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-3996) Document fetch profiles

by Steve Ebersole (JIRA)

Document fetch profiles ----------------------- Key: HHH-3996 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3996 Project: Hibernate Core Issue Type: Task Components: documentation Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 3.5 -- 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

15 years, 6 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-3995) Restrictions should honor expressions and functions

by Tarik Makota (JIRA)

Restrictions should honor expressions and functions --------------------------------------------------- Key: HHH-3995 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3995 Project: Hibernate Core Issue Type: New Feature Reporter: Tarik Makota When using Restrictions where 2 columns/properties need to be concatanated and then compared to value hibernate is unable to do so. Example: PoJo: TABLE SNIPPET: ---------------------------------------------- FIRSTNAME VARCHAR2(50) LASTNAME VARCHAR2(50) JAVA ENTITY: ---------------------------------------------- @Colum (name="FIRSTNAME") private String firstName; @Colum (name="LASTNAME") private String lastName; ACTUAL PROBLEM (trivial example): ----------------------------------------------- Criteria crit.add(Restrictions.in( "concat(firstName,lastName) ", parmUserFullName)); << concat doesnt work -- 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

15 years, 6 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HV-165) Hibernate Validator does not validate groups in class level annotations.

by Juan Pablo Soto (JIRA)

Hibernate Validator does not validate groups in class level annotations. ------------------------------------------------------------------------ Key: HV-165 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-165 Project: Hibernate Validator Issue Type: Bug Affects Versions: 4.0.0.Beta2 Reporter: Juan Pablo Soto -- 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

15 years, 6 months

2
4
0 / 0

[Hibernate-JIRA] Commented: (HBX-623) Add ability in reverse engineering config file to support cascades

by toni garcia (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-623?page=co... ] toni garcia commented on HBX-623: --------------------------------- Hi Max, trying to overryde foreignKeyToAssociationInfo, i think i'm missing something here; properties are always generated lazy, no mather what fetch i set in the AssociationInfo. I think this is because EntityPojoClass is using value.isLazy() instead of property.isLazy() so you must set this also: value.setLazy(value.getFetchMode()!=FetchMode.JOIN); return this.makeProperty(TableIdentifier.create( table ), propertyName, value, insert, update, value.getFetchMode()!=FetchMode.JOIN, cascade, null); Not sure about this, cause I don't khow nothing about hibernate code. > Add ability in reverse engineering config file to support cascades > ------------------------------------------------------------------ > > Key: HBX-623 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-623 > Project: Hibernate Tools > Issue Type: Patch > Components: reverse-engineer > Affects Versions: 3.0beta2 > Environment: Hibernate Tools Beta 5 > Reporter: tony anecito > Assignee: Anthony Patricio > Priority: Critical > Fix For: 3.2.4.GA > > Attachments: many-to-one-attributes-with-test.diff, many-to-one-attributes.diff > > > Please add ability to add cascade tag to resultant mapping files in the reveng file. Currently have to modifiy velocity template file -- 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

15 years, 6 months

1
0
0 / 0

[Hibernate-JIRA] Commented: (HBX-622) Allow ability to ignore Foreign Keys

by Lajos Gathy (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-622?page=co... ] Lajos Gathy commented on HBX-622: --------------------------------- I also ran into this problem and I think I found an other solution, maybe it is a bit simpler: I noticed that the org.hibernate.cfg.reveng.ReverseEngineeringSettings class contains these properties: createManyToOneForForeignKey and createCollectionForForeignKey. They are both set to true, and you cannot set them on the Hibernate Code Generation Configurations dialog. But since I already had my own reveng strategy implementation (inherited from DelegatingReverseengineeringStrategy of course), I used the setSettings method to change these two properties to false: private ReverseEngineeringSettings settings; @Override public void setSettings(ReverseEngineeringSettings settings) { settings.setCreateManyToOneForForeignKey(false); settings.setCreateCollectionForForeignKey(false); this.settings = settings; super.setSettings(settings); } This way the generated POJOs did not contain the @ManyToOne/@OneToMany associations for the FKs (however there were some blank lines generated in the source). I am not sure, if this works with HT 3.1 (I used 3.2.4). > Allow ability to ignore Foreign Keys > ------------------------------------ > > Key: HBX-622 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-622 > Project: Hibernate Tools > Issue Type: New Feature > Components: reverse-engineer > Affects Versions: 3.1beta4 > Environment: As per patch. > Reporter: James Olsen > Fix For: 3.2.beta11 > > Attachments: svn-patch.txt > > > On the project I'm currently working on we want 1:1 POJO<->Table mapping without any relationships between the POJOs. Although this is not a configuration that I would normally choose or recommend, in this case it is forced upon us be external architectural requirements. > Currently in order to avoid relationships in your POJOs you have to reveng each table individually. The attached patch is a proposed solution to allow the reveng to ignore relationships between tables when reverse engineering multiple tables at the same time. > Note that the patch only supports this for ReverseEngineeringStrategy not for reveng.xml. > I'm supplying the patch in the hope that it (or something similar) can be incorporated into the main code and in case anyone else has (unfortunately) similar requirements. -- 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

15 years, 6 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HV-131) Support @DecimalMin / @DecimalMax

by Emmanuel Bernard (JIRA)

Support @DecimalMin / @DecimalMax --------------------------------- Key: HV-131 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-131 Project: Hibernate Validator Issue Type: New Feature Components: validators Reporter: Emmanuel Bernard -- 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

15 years, 6 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HV-138) JPAValidateListener checks @NotNull fields that are filled after the @PrePersist call

by Julien Kronegg (JIRA)

JPAValidateListener checks @NotNull fields that are filled after the @PrePersist call ------------------------------------------------------------------------------------- Key: HV-138 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-138 Project: Hibernate Validator Issue Type: Bug Affects Versions: 3.1.0.GA Environment: Hibernate 3.3.1.GA, Hibernate annotations 3.4.0.GA, Hibernate entity manager 3.4.0.GA, POJO annotated entities, DB2 Reporter: Julien Kronegg According to Hibernate validation documentation ( http://www.hibernate.org/hib_docs/validator/reference/en/html_single/#val... ) we can annotate an entity with @EntityListeners({JPAValidateListener.class}) to validate the fields using the @PrePersist / @PreUpdate JPA events handlers. I tryied with the following entity: @Entity @Table(...) @EntityListeners({JPAValidateListener.class}) public class A { private int id; private String text; @Id @Column(...) @NotNull @GeneratedValue(...) @GenericGenerator(...) public int getId() { return id; } public void setId(int id) { this.id=id; } ... } Problem is that the @PrePersist event is raised before some fields are automatically filled (e.g. @Id annotated). So the JPAValidateListener raises an exception saying that the identifier cannot be null. The exception root cause detail is (InvalidState: id cannot be null) and the stacktrace is: org.hibernate.validator.InvalidStateException: validation failed for : my.package.A at org.hibernate.validator.ClassValidator.assertValid(ClassValidator.java:666) at org.hibernate.validator.event.JPAValidateListener.onChange(JPAValidateListener.java:62) ...// some reflection StacktraceElement at org.hibernate.ejb.event.ListenerCallback.invoke(ListenerCallback.java:31) at org.hibernate.ejb.event.EntityCallbackHandler.callback(EntityCallbackHandler.java:80) at org.hibernate.ejb.event.EntityCallbackHandler.preCreate(EntityCallbackHandler.java:49) at org.hibernate.ejb.event.EJB3PersistEventListener.saveWithGeneratedId(EJB3PersistEventListener.java:48) at org.hibernate.event.DefaultPersistEventListener.entityIsTransient(DefaultPersistEventListener.java:154) at org.hibernate.event.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:110) at org.hibernate.event.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:61) at org.hibernate.impl.SessionImpl.firePersist(SessionImpl.java:645) at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:619) at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:623) ... The EJB3PersistEventListener.saveWithGeneratedId() method looks like: protected Serializable saveWithGeneratedId(...) { callbackHandler.preCreate(entity); // raises the @PrePersist JPA event return super.saveWithGeneratedId(...); // sets the identifier } Thus, the JPAValidateListener validates the whole Entity and does not take the entity lifecycle into account. The JPAValidateListener should check all fields except the ones which are known to be modified/setled after the call to the validator. This may also be the case for other generated fields such as the ones annotated with @Version (I did not check that). -- 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

15 years, 6 months

2
3
0 / 0

[Hibernate-JIRA] Created: (ANN-746) Implemented BigDecimalRange Validator for BigDecimals with precision range and scale

by Priya M (JIRA)

Implemented BigDecimalRange Validator for BigDecimals with precision range and scale ------------------------------------------------------------------------------------ Key: ANN-746 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-746 Project: Hibernate Annotations Issue Type: New Feature Reporter: Priya M Attachments: BigDecimalRange.java, BigDecimalRangeValidator.java Currently, hibernate validator's do not have @Range or @Length for decimal numbers (like float, double and BigDecimal) for validating precision and scale simultaneously. Also, Hibernate doesn't generate correct db column types as Number(x,y) if Java Type is Float or Double. However it works only for BigDecimal. I've added the annotation for BigDecimalRange and BigDecimalRangeValidator for the same Usage @BigDecimalRange(minPrecision=0, maxPrecision=13, scale=2) public BigDecimal getFoo() { return this.foo; } It works for my app. -- 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

15 years, 6 months

2
2
0 / 0

[Hibernate-JIRA] Created: (BVAL-12) <T> in ValidatorContext<T> Validator<T> and InvalidConstraint<T> are inadequately considered unique

by Emmanuel Bernard (JIRA)

<T> in ValidatorContext<T> Validator<T> and InvalidConstraint<T> are inadequately considered unique --------------------------------------------------------------------------------------------------- Key: BVAL-12 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-12 Project: Bean Validation Issue Type: Sub-task Components: ri-general Reporter: Emmanuel Bernard Assignee: Hardy Ferentschik In ValidatorImpl.validate() T Generic of ValidatorContext<T> and InvalidConstraint<T> are likely to be different than the Validator<T> A context can be created in a validator (T are equal). but the same context (a clone really) can be passed to a sub validator. Ts are then different. I believe it's the same for InvalidConstraints. An IC created by a subvalidator<U> will craete IC<U>, you will need to convert them in IC<T> when coming to the root validator<T>. So we need something like private <U> List<InvalidConstraintImpl<T>> validate(ValidationContext<U> context, List<String> groups) { } same for similar methods. -- 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

15 years, 6 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-3233) Integer overflow in TableHiLoGenerator

by Hauke Rabe (JIRA)

Integer overflow in TableHiLoGenerator --------------------------------------- Key: HHH-3233 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3233 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.2 Reporter: Hauke Rabe The TableGenerator use for id generation the type INTEGER. The subclass TableHiLoGenerator use these id for multiplication with the maxLo value. But if you mutiply two int and assign the result to a long you can get an integer overflow. The TableGenerator should work with long values, or must be able to configure. -- 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

15 years, 6 months

2
1
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues June 2009