hibernate-issues April 2009

hibernate-issues@lists.jboss.org

1 participants
875 discussions

[Hibernate-JIRA] Commented: (HHH-1501) Derby 10 varchar limit is 32672

by Steven Swor (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1501?page=c... ] Steven Swor commented on HHH-1501: ---------------------------------- This is a documented issue with Derby: http://issues.apache.org/jira/browse/DERBY-102 The Derby team's "fix" was to make their documentation reflect the ~32K character limit instead of increasing the limit itself. So, to make a long story short, Derby doesn't allow VARCHAR, LONG VARCHAR, VARCHAR FOR BIT DATA, or LONG VARCHAR FOR BIT DATA columns longer than ~32K. So it sounds like the real "fix" for Hibernate would be for someone to go into the Derby project and increase the limit there. > Derby 10 varchar limit is 32672 > -------------------------------- > > Key: HHH-1501 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1501 > Project: Hibernate Core > Issue Type: Bug > Components: core > Affects Versions: 3.1.2 > Environment: Derby 10 > Reporter: Sergey Vladimirov > Priority: Trivial > > Derby 10 varchar limit is 32672. > One need to change DB2Dialect and DerbyDialect to create clob columns, if size of text > 32k: > registerColumnType(Types.CHAR, 254, "char(1)"); > registerColumnType(Types.VARCHAR, 32672, "varchar($l)"); > registerColumnType(Types.VARCHAR, Integer.MAX_VALUE, "clob($l)"); > (BTW, char limit is 254). -- 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, 9 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HV-111) Bootstrap HV using validation.xml

by Hardy Ferentschik (JIRA)

Bootstrap HV using validation.xml --------------------------------- Key: HV-111 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-111 Project: Hibernate Validator Issue Type: Task Components: engine Reporter: Hardy Ferentschik Fix For: 4.0.0.Beta1 -- 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, 9 months

1
2
0 / 0

[Hibernate-JIRA] Created: (HHH-3846) LazyInit error on persting with detached association

by Shorn Tolley (JIRA)

LazyInit error on persting with detached association ---------------------------------------------------- Key: HHH-3846 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3846 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.3.1, 3.2.5 Environment: Reproduced on 3.2.5 and 3.3.1 on Ingres and Postgress databases. Reporter: Shorn Tolley Attachments: patch.txt, Sample.zip Basically, the scenario is, if you try to persist an object that has a detached association AND the target of that association has been loaded by some other code for the same session. When the above conditions are met, Hibernate will throw a LazyInitException during th persist() operation - which if you think about, doesn't really make much sense. It is not feasible to reset the association to point to the attached version of the object, as the two pieces of code are completely orthogonal, they just happen to refer to the same object within the scope of a single session. This kind of scenario will occur on any sufficiently complex project. More details can be found here in this forum post: http://forum.hibernate.org/viewtopic.php?t=995977 I have attached some sample code to reproduce the error in as simple a manner as possible: sample.zip I have also attached a patch with the change suggested by "nordborg" on the forum: patch.txt -- 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, 9 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-3845) patch --help

by Shorn Tolley (JIRA)

patch --help ------------ Key: HHH-3845 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3845 Project: Hibernate Core Issue Type: Bug Reporter: Shorn Tolley -- 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, 9 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HHH-3840) Export non-infected object trees without collection wrappes

by Alexander Rau (JIRA)

Export non-infected object trees without collection wrappes ----------------------------------------------------------- Key: HHH-3840 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3840 Project: Hibernate Core Issue Type: Improvement Reporter: Alexander Rau There has been lots of discussion on the web about "getting rid" of hibernate classes inside a loaded object tree so it seems like there is a notable demand for improvement here. Two real-world use cases where obtaining a "non-infected" object tree from a session IMHO should be possible and would help a lot: 1) Exporting an eagerly loaded object model to XML with 3rd party libraries by using reflection (e.g. xstream): Workaround proposals in general perform a cleaning on the object model *after* receiving it from the session. Either traversing the object tree "on their own" and replacing the hibernate collection wrappers with their original java.util.* classes or post-processing generated xml and filtering out hibernate-specific tags. It would be clearly simpler and less error prone if hibernate would help here already (imagine cleaning an object tree with circular/bidirectional references and dozens of collections !). Furthermore this clearly shows the conflict here: first hibernate injects collections wrappers and the application code immediately tries to get rid of them. 2) (Web-layer) Session persistence: Increased amount of space consumed as the collection wrappers need to be persisted as well even when it's clear that the objects won't be used again for updating data via hibernate (e.g. read-only views). Again application-level clean out code is required if hibernate does not help in getting a clean model. There are certainly more use cases. The described problems could be nicely solved in a general manner and remove the burden of the application programmer of post-cleaning tasks if the hibernate session would allow to retrieve "clean" objects (by introducing a new method session.export(..) for example which could be similar to session.load(..) ). Session.export(..) would then return the object tree without collection wrappers but instead with their original collection pendants. This would perfectly fit the concept of persisting new objects. The state of an exported object would be exactly the same as the state of a new object which has not yet been passed to the hibernate layer. -- 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, 9 months

1
1
0 / 0

← Newer
1
...
85
86
87
88
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues April 2009