[Hibernate-JIRA] Commented: (HHH-1501) insert long string (more than 32700) fails on derby
by Steve Ebersole (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1501?page=c... ]
Steve Ebersole commented on HHH-1501:
-------------------------------------
Hibernate does not take into account the length/scale/precision nor the dialect when determining the Hibernate Type to use for a property which omitted specifying one. What it does is to basically choose a default based solely on the Java type. Using that it performs a lookup via a call to TypeFactory.heuristicType.
What we'd need to do here is to inject a process that consults the dialect based on the sql-type (from the resolved Hibernate Type) and length and asks whether it should use an alternate Hibernate Type (aka, instead of StringType[String->VARCHAR] use MaterializeClobType[String->CLOB] because the length exceeded some limit for that dialect.
That I'd be OK with. Problem is that the dialect is not known when we are doing this process :( This is something I plan on addressing, but not until 3.7 or later. See HHH-2578 for the details of that
> insert long string (more than 32700) fails on derby
> ---------------------------------------------------
>
> Key: HHH-1501
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1501
> Project: Hibernate Core
> Issue Type: Bug
> Components: core
> Affects Versions: 3.5.0-Beta-2
> Environment: Derby 10
> Reporter: Sergey Vladimirov
> Priority: Trivial
>
> http://issues.apache.org/jira/browse/DERBY-102
> VARCHAR maximum length 32 672
> LONG VARCHAR maximum length 32 700
> CLOB maximum length 2 147 483 647
> BLOB maximum length 2 147 483 647
> this issue can be reproduced by org.hibernate.test.lob.TextTest (in 3.5 beta1,2) with change org.hibernate.test.lob.LongStringTest.LONG_STRING_SIZE > 32700
--
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, 7 months
[Hibernate-JIRA] Commented: (HBX-633) Reverse engineered VERSION columns cause ClassCastException
by Taran Preet Singh Sodhi (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-633?page=co... ]
Taran Preet Singh Sodhi commented on HBX-633:
---------------------------------------------
I' am facing the same issue in reverse enginering and can't afford to have a manual intervention to control it due to daily build. Can we get a solution
> Reverse engineered VERSION columns cause ClassCastException
> -----------------------------------------------------------
>
> Key: HBX-633
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-633
> Project: Hibernate Tools
> Issue Type: Bug
> Affects Versions: 3.1beta4
> Environment: Oracle 8i, ojdbc14.jar
> Reporter: Gabor Kincses
>
> Exception in thread "main" java.lang.ClassCastException: org.hibernate.type.BigDecimalType
> at org.hibernate.tuple.PropertyFactory.buildVersionProperty(PropertyFactory.java:83)
> at org.hibernate.tuple.EntityMetamodel.<init>(EntityMetamodel.java:157)
> at org.hibernate.persister.entity.AbstractEntityPersister.<init>(AbstractEntityPersister.java:412)
> at org.hibernate.persister.entity.SingleTableEntityPersister.<init>(SingleTableEntityPersister.java:108)
> at org.hibernate.persister.PersisterFactory.createClassPersister(PersisterFactory.java:55)
> at org.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:216)
> at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1176)
> at com.paypal.bdo.test.Hibernate101.main(Hibernate101.java:37)
> I guess the code tries to cast the type to VersionType.
--
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, 7 months
[Hibernate-JIRA] Created: (HV-305) JPATraversableResolver tries to access properties that do not exist
by Stephan Bublava (JIRA)
JPATraversableResolver tries to access properties that do not exist
-------------------------------------------------------------------
Key: HV-305
URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-305
Project: Hibernate Validator
Issue Type: Bug
Affects Versions: 4.1.0.Beta1
Environment: Hibernate Validator 4.1.0.Beta1, Hibernate 3.5.0-Final
Reporter: Stephan Bublava
Assignee: Hardy Ferentschik
Attachments: validation-test.zip
Prerequisites:
- two entities that model a bidirectional 1:n relationship
- both have class-level constraints
- the collection that represent the n-side of the relationship is annotated @Valid
- Hibernate 3.5 is in the class path
In this case, validation of the entity that represents the 1-side fails, because JPATraversableResolver attempts to access a property that doesn't exist. (It looks for the collection in the wrong entity.)
Changing any of the last three conditions makes the problem disappear...
I've attached a test-cases that demonstrates this issue in more detail.
--
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, 7 months