[Hibernate-JIRA] Created: (HHH-2511) generated="insert/always" ignored for property in composite-element?
by James Garrison (JIRA)
generated="insert/always" ignored for property in composite-element?
--------------------------------------------------------------------
Key: HHH-2511
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2511
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.2
Environment: Hibernate 3.2.2, Windows XP SP2, Oracle 9i
Reporter: James Garrison
Priority: Minor
I have a composite-element (in an idbag) that has a db-generated timestamp
property. I have defined the property with update="false" insert="false" generated="insert",
but Hibernate is trying to insert a null value when saving a transient object.
See below, the "createTs" property (column=CREATE_TS) in the "comments"
composite-element.
DDL:
create table CR_COMMENT
(
COMMENT_ID integer not null,
REQ_ID integer not null,
CREATE_TS timestamp default sysdate not null,
SECTION_ID char(1) not null,
USER_ID varchar2(20) not null,
TEXT varchar2(4000) not null,
primary key(COMMENT_ID),
foreign key(REQ_ID) references CR_REQUEST (REQ_ID) on delete cascade
);
Mapping:
<?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 package="com.wholefoods.ittoolkit.ws.ccf">
<class name="Request" table="CR_REQUEST">
<id name="reqId" column="REQ_ID" type="long">
<generator class="sequence">
<param name="sequence">CR_REQUEST_ID</param>
</generator>
</id>
[snip]
<idbag name="comments" table="CR_COMMENT">
<collection-id type="long" column="COMMENT_ID">
<generator class="sequence">
<param name="sequence">CR_COMMENT_ID</param>
</generator>
</collection-id>
<key column="REQ_ID" />
<composite-element class="Comment">
<property name="createTs" column="CREATE_TS"
type="calendar"
access="field"
update="false"
insert="false"
generated="insert" />
<property name="sectionId" column="SECTION_ID" />
<property name="userId" column="USER_ID" />
<property name="text" column="TEXT"/>
</composite-element>
</idbag>
</class>
</hibernate-mapping>
Log Output:
Hibernate:
/* insert collection
row com.wholefoods.ittoolkit.ws.ccf.Request.comments */ insert
into
ITTOOLKIT.CR_COMMENT
(REQ_ID, COMMENT_ID, CREATE_TS, SECTION_ID, USER_ID, TEXT)
values
(?, ?, ?, ?, ?, ?)
10:15:01,659 DEBUG org.hibernate.jdbc.AbstractBatcher:476 - preparing statement
10:15:01,675 DEBUG org.hibernate.type.LongType:133 - binding '47' to parameter: 1
10:15:01,675 DEBUG org.hibernate.type.LongType:133 - binding '7' to parameter: 2
10:15:01,675 DEBUG org.hibernate.type.CalendarType:126 - binding null to parameter: 3
10:15:01,675 DEBUG org.hibernate.type.StringType:133 - binding 'A' to parameter: 4
10:15:01,690 DEBUG org.hibernate.type.StringType:133 - binding 'garrisoj' to parameter: 5
10:15:01,690 DEBUG org.hibernate.type.StringType:133 - binding 'This is a test comment' to parameter: 6
10:15:01,690 DEBUG org.hibernate.persister.collection.AbstractCollectionPersister:1172 - done inserting collection: 1 rows inserted
10:15:01,690 DEBUG org.hibernate.jdbc.AbstractBatcher:44 - Executing batch size: 1
10:15:01,737 DEBUG org.hibernate.jdbc.AbstractBatcher:366 - about to close PreparedStatement (open PreparedStatements: 1, globally: 1)
10:15:01,737 DEBUG org.hibernate.jdbc.AbstractBatcher:525 - closing statement
10:15:01,768 DEBUG org.hibernate.util.JDBCExceptionReporter:69 - Could not execute JDBC batch update
[/* insert collection row com.wholefoods.ittoolkit.ws.ccf.Request.comments */
insert into ITTOOLKIT.CR_COMMENT (REQ_ID, COMMENT_ID, CREATE_TS, SECTION_ID, USER_ID, TEXT)
values (?, ?, ?, ?, ?, ?)]
java.sql.BatchUpdateException: ORA-01400: cannot insert NULL into ("ITTOOLKIT"."CR_COMMENT"."CREATE_TS")
--
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
13 years
[Hibernate-JIRA] Created: (HHH-6063) The fix for HHH-5126 breaks array constructor in PostgreSQL
by Jon Vincent (JIRA)
The fix for HHH-5126 breaks array constructor in PostgreSQL
-----------------------------------------------------------
Key: HHH-6063
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6063
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 4.0.0.Alpha1, 3.6.2, 3.6.1
Environment: PostgreSQL, any version
Reporter: Jon Vincent
The fix for HHH-5126 supports this JPA2-compliant IN query:
{{{
SELECT * FROM my_table WHERE id IN :collection
}}}
Before HHH-5126 was fixed, Hibernate required the developer to surround collection-valued parameters with parentheses:
{{{
SELECT * FROM my_table WHERE id IN (:collection)
}}}
The implemented fix was simply to output parentheses in the generated SQL. Unfortunately, this breaks _other_ uses of collection-values parameters, such as for arrays in PostgreSQL:
{{{
CREATE TABLE my_table (some_array INTEGER[]);
INSERT INTO my_table (some_array) VALUES (ARRAY[:collection]);
}}}
Is there a way to turn off the fix for HHH-5126? For us, at least, the old code was more flexible and allowed access to important database features.
--
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
13 years
[Hibernate-JIRA] Created: (HHH-2455) "Could not close a JDBC result set" output very often
by Dirk Feufel (JIRA)
"Could not close a JDBC result set" output very often
-----------------------------------------------------
Key: HHH-2455
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2455
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.2
Reporter: Dirk Feufel
Priority: Minor
If you call this type of code (like the DbTimestampType class does), the AbstractBatcher outputs a warning "Could not close a JDBC result set".
The problem should be that closing the prepared statement internally also closes the associated result sets and the AbstractBatcher still has a reference to this result set.
One possible solution might be to provide an additional method
public void closeStatement(PreparedStatement ps, ResultSet rs);
(as already present for closeQueryStatement) in the AbstractBatcher allowing to close both in the right order.
PreparedStatement ps = null;
try {
ps = session.getBatcher().prepareStatement( timestampSelectString );
ResultSet rs = session.getBatcher().getResultSet( ps );
....
} finally {
if ( ps != null ) {
session.getBatcher().closeStatement( ps );
}
}
--
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
13 years
[Hibernate-JIRA] Created: (HV-482) Weblogic ConstrantDeclationException HVbeta2
by Tim Canavan (JIRA)
Weblogic ConstrantDeclationException HVbeta2
--------------------------------------------
Key: HV-482
URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-482
Project: Hibernate Validator
Issue Type: Bug
Affects Versions: 4.2.0.Beta2
Environment: Weblogic 10.3
Reporter: Tim Canavan
After upgrading to HV beta2 and changing all our validations to be at the interface level
we get the constraint declaration exception
Caused by: javax.validation.ConstraintDeclarationException: Only the root method of an overridden method in an inheritance hierarchy may be annotated with parameter constraints. The following method itself has no parameter constraints but it is not defined on a sub-type of class
Under OpenEJB which our unit tests use everything works fine.
Is there any code that HV could use that would allow it to understand these proxies or would an option be available
to turn the check off.
--
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
13 years
[Hibernate-JIRA] Created: (HHH-5948) Trying to get a PluralAttributePath from a @MappedSuperclass throws org.hibernate.MappingException: Unknown collection role
by Oliver Ringel (JIRA)
Trying to get a PluralAttributePath from a @MappedSuperclass throws org.hibernate.MappingException: Unknown collection role
----------------------------------------------------------------------------------------------------------------------------
Key: HHH-5948
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5948
Project: Hibernate Core
Issue Type: Bug
Affects Versions: 3.6.1, 3.6.0
Reporter: Oliver Ringel
Attachments: testcase-hibernate.tgz
I'm trying to get the PluralAttributePath from a collection defined in a MappedSuperclass
@Entity
public class Person extends PersonBase {
@Basic
private String name;
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
@MappedSuperclass
public abstract class PersonBase {
@Id
private String id;
public String getId() {
return id;
}
public void setId(String id) {
this.id = id;
}
@OneToMany()
private Set<Address> addresses = new HashSet<Address>();
public Set<Address> getAddresses() {
return addresses;
}
public void setAddresses(Set<Address> addresses) {
this.addresses = addresses;
}
}
Executing the following
criteriaQuery = criteriaBuilder.createQuery(Person.class);
root = criteriaQuery.from(Person.class);
Path<?> pathAddresses = root.get("addresses");
throws the exception
org.hibernate.MappingException: Unknown collection role: testcase.hibernate.PersonBase.addresses
at org.hibernate.impl.SessionFactoryImpl.getCollectionPersister(SessionFactoryImpl.java:701)
at org.hibernate.ejb.criteria.path.PluralAttributePath.resolvePersister(PluralAttributePath.java:58)
at org.hibernate.ejb.criteria.path.PluralAttributePath.<init>(PluralAttributePath.java:52)
at org.hibernate.ejb.criteria.path.AbstractPathImpl.get(AbstractPathImpl.java:157)
at org.hibernate.ejb.criteria.path.AbstractPathImpl.get(AbstractPathImpl.java:197)
at testcase.hibernate.HibernateTest.testMappedSuperclassPluralAttribute(HibernateTest.java:53)
--
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
13 years
[Hibernate-JIRA] Created: (HV-512) Composed constraints lose the payload information of the constraints they are composed of
by Geoff The (JIRA)
Composed constraints lose the payload information of the constraints they are composed of
-----------------------------------------------------------------------------------------
Key: HV-512
URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-512
Project: Hibernate Validator
Issue Type: Bug
Components: validators
Affects Versions: 4.2.0.Final
Reporter: Geoff The
If a payload is set for child constraints in a composed constraint, their payload values will be ignored.
HV-183 dealt with the propagation of the parent's payload down to the children constraints, but it also overwrites any payload the children may have had.
I would suggest that if the children have any explicit payloads defined, they should be integrated into the parents and not blown away.
{code}
import org.junit.*;
import javax.validation.*;
import javax.validation.constraints.NotNull;
import java.lang.annotation.*;
import java.util.*;
import static org.junit.Assert.*;
import static java.lang.annotation.ElementType.*;
import static java.lang.annotation.RetentionPolicy.*;
public class TestPayload {
public static class Warning implements Payload {}
public static class Error implements Payload {}
@Documented
@Constraint(validatedBy = NameMustBeGeoffValidator.class)
@Target({ TYPE, METHOD, FIELD, ANNOTATION_TYPE, CONSTRUCTOR, PARAMETER })
@Retention(RUNTIME)
public @interface NameMustBeGeoff {
String message() default "{NameMustBeGeoff.message}";
Class<?>[] groups() default {};
Class<? extends Payload>[] payload() default {};
}
public static class NameMustBeGeoffValidator implements ConstraintValidator<NameMustBeGeoff, Customer> {
@Override
public void initialize(NameMustBeGeoff constraintAnnotation) {}
@Override
public boolean isValid(Customer value, ConstraintValidatorContext context) {
return ((value.getName() == null) || (value.getName().equals("Geoff")));
}
}
@NameMustBeGeoff(payload = Error.class)
@Documented
@Constraint(validatedBy = ValidCustomerValidator.class)
@Target({ TYPE, METHOD, FIELD, ANNOTATION_TYPE, CONSTRUCTOR, PARAMETER })
@Retention(RUNTIME)
public @interface ValidCustomer {
String message() default "{ValidCustomer.message}";
Class<?>[] groups() default {};
Class<? extends Payload>[] payload() default {};
}
public static class ValidCustomerValidator implements ConstraintValidator<ValidCustomer, Customer> {
@Override
public void initialize(ValidCustomer constraintAnnotation) {}
@Override
public boolean isValid(Customer value, ConstraintValidatorContext context) { return true; }
}
@ValidCustomer
public class Customer {
private String name;
public Customer(String name) { this.name = name; }
@NotNull(payload = Warning.class)
public String getName() { return this.name; }
}
/**
* Customer's name is null, it should trigger the @NotNull with a Warning payload
*/
@Test
public void test() {
ValidatorFactory factory = Validation.buildDefaultValidatorFactory();
Validator validator = factory.getValidator();
Customer customer = new Customer(null);
Set<ConstraintViolation<Customer>> violations = validator.validate(customer);
assertEquals(1, violations.size());
ConstraintViolation<Customer> violation = violations.iterator().next();
assertEquals("may not be null", violation.getMessage());
assertEquals("javax.validation.constraints.NotNull", violation.getConstraintDescriptor().getAnnotation().annotationType().getName());
assertEquals(1, violation.getConstraintDescriptor().getPayload().size());
assertEquals(Warning.class, violation.getConstraintDescriptor().getPayload().iterator().next());
}
/**
* Customer's name is not Geoff and should trigger the NameMustBeGeoff constraint, but the Error payload is lost
*/
@Test
public void testPayloadInComposedConstraints() {
ValidatorFactory factory = Validation.buildDefaultValidatorFactory();
Validator validator = factory.getValidator();
Customer customer = new Customer("Bob");
Set<ConstraintViolation<Customer>> violations = validator.validate(customer);
assertEquals(1, violations.size());
ConstraintViolation<Customer> violation = violations.iterator().next();
assertEquals("{NameMustBeGeoff.message}", violation.getMessage());
assertEquals("org.geofft.TestPayload$NameMustBeGeoff", violation.getConstraintDescriptor().getAnnotation().annotationType().getName());
assertEquals(0, violation.getConstraintDescriptor().getPayload().size()); // Not what I expected
/*
What I think should happen:
assertEquals(1, violation.getConstraintDescriptor().getPayload().size());
assertEquals(Customer.Error.class, violation.getConstraintDescriptor().getPayload().iterator().next());
*/
}
}
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years