[Hibernate-JIRA] Created: (HBX-1151) let JDBCBinder check for excluded foreign key columns in many-to-many tables
by Andreas Brieg (JIRA)
let JDBCBinder check for excluded foreign key columns in many-to-many tables
----------------------------------------------------------------------------
Key: HBX-1151
URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-1151
Project: Hibernate Tools
Issue Type: Patch
Affects Versions: 3.2.4.GA
Environment: hibernate-tools revision 17926
Reporter: Andreas Brieg
Priority: Minor
Attachments: jdbcbinder_check_foreignkey_excluded_for_many_to_many_table.patch
When processing a many-to-many table the JDBCBinder looks only for other foreign key columns in the many-to-many table in method bindOneToMany(PersistentClass, ForeignKey, Set, Mapping) but it doesn't ask the reverse engineering strategy if those foreign key columns are excluded.
The patch changes the bindOneToMany(PersistentClass, ForeignKey, Set, Mapping) method when processing a many-to-many table so that it asks the reverse engineering strategy if the foreign key is excluded. Only if it isn't excluded it is chosen for the mapping of the other side of the many-to-many table.
This lets you map tables many-to-many tables, which have a third optional foreign key. This may be needed in case the optional foreign key is only used by other modules, which access the database.
--
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, 5 months
[Hibernate-JIRA] Created: (HHH-3529) ConnectionWrapper is not visible from class loader
by Vladimir Kralik (JIRA)
ConnectionWrapper is not visible from class loader
---------------------------------------------------
Key: HHH-3529
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3529
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.3.1, 3.2.6
Environment: SpringFramework 2.5.5, Hibernate 3.2.6 / 3.3.1, Tomcat 5.5, CommonJ Timer ( http://www.myfoo.de/commonj/ )
Reporter: Vladimir Kralik
Attachments: hibernate-3.2.6_p2.patch
Hibernate/Spring libraries are in app.war/WEB-INF/lib.
Timer is configured as resources in Tomcat and his libraries are in $CATALINA_HOME/common/lib/.
Function call from GUI works, but the same function called by timers gives this exception :
org.springframework.transaction.CannotCreateTransactionException: Could not openHibernate Session for transaction; nested exception is java.lang.IllegalArgumentException:
interface org.hibernate.jdbc.ConnectionWrapper is not visible from class loader
at org.springframework.orm.hibernate3.HibernateTransactionManager.doBegin(HibernateTransactionManager.java:599)
....
Caused by: java.lang.IllegalArgumentException: interface org.hibernate.jdbc.ConnectionWrapper is not visible from class loader
at java.lang.reflect.Proxy.getProxyClass(Proxy.java:353)
at java.lang.reflect.Proxy.newProxyInstance(Proxy.java:581)
at org.hibernate.jdbc.BorrowedConnectionProxy.generateProxy(BorrowedConnectionProxy.java:67)
at org.hibernate.jdbc.ConnectionManager.borrowConnection(ConnectionManager.java:163)
at org.hibernate.jdbc.JDBCContext.borrowConnection(JDBCContext.java:111)
at org.hibernate.impl.SessionImpl.connection(SessionImpl.java:359)
at org.springframework.orm.hibernate3.HibernateTransactionManager.doBegin(HibernateTransactionManager.java:510)
It's the same bug as was in HHH-2215, but this is not resolved.
I think, that the problem is extracting classloader from currentThread(). This is always not null, so the next test in method getProxyClassLoader() is always false.
I my case, timer thread lives in top class loader, but hibernate libraries are inside application class loader.
Attached patch removes classloader extracting from currentThread(). It works for my case.
--
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, 5 months
[Hibernate-JIRA] Created: (ANN-748) @JoinColumn overrides scale and percision in ManyToOne map..
by Andrew C. Oliver (JIRA)
@JoinColumn overrides scale and percision in ManyToOne map..
------------------------------------------------------------
Key: ANN-748
URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-748
Project: Hibernate Annotations
Issue Type: Bug
Affects Versions: 3.4.0.CR1
Environment: Postgresql but not Hypersonic (haven't tried other DBs, but suspect any real non-java db will replicate)
Reporter: Andrew C. Oliver
Attachments: patch.tar.gz
http://forum.hibernate.org/viewtopic.php?t=987527
Since you asked nicely...
This is a patch against your test cases.
Sorry for the not patch style patch. It is against the latest download of Annotations (3.4.0.CR1). I'm on a hotel network that seems to really make SVN angry.
There are 4 files:
1. Bunny has many
2. PointyTooth (teeth)
3. IdTest.java, only "testBlownPrecision" is new and "getMappings" includes the rabid bunny and teeth
4. UUIDGenerator - I wouldn't have included it but I couldn't find a decent way to autogenerate 128-bit keys. (The linked wikipedia article is amusing).
You'll probably want to unzip these into the annotations root directory, then do the svn diff. Following this you may want to pretty print.
As the test notes, it will FAIL with the @JoinColumn mapping and succeed if it is commented out. The failure notes a precision error. Obviously batching must be disabled to read it. If you look at the generated table it will have like NUMBER[19]. With JoinColumn commented out it is the expected NUMBER[128]. Thanks to PaaKow Acquah for finding this.
If you want more details, I'll be a TacoMac having another Aventinus...
--
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, 5 months
[Hibernate-JIRA] Closed: (HHH-611) ID generator using Oracle-style sequences with increment
by Steve Ebersole (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-611?page=co... ]
Steve Ebersole closed HHH-611.
------------------------------
Resolution: Rejected
This is out of date. Have a look at org.hibernate.id.enhanced.SequenceStyleGenerator
> ID generator using Oracle-style sequences with increment
> --------------------------------------------------------
>
> Key: HHH-611
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-611
> Project: Hibernate Core
> Issue Type: Patch
> Affects Versions: 3.0.5
> Environment: Hibernate 3, Oracle
> Reporter: Binil Thomas
> Assignee: Steve Ebersole
> Priority: Minor
> Attachments: caching-sequence-test.patch, caching-sequence.patch
>
>
> The org.hibernate.id.SequenceGenerator can be used to generate id's based on Oracle-style database sequences. But in its current form, this id generator does not use 'increment' option. It will hit the DB everytime it is used.
> A more efficient implementation is the org.hibernate.id.SequenceHiLoGenerator. This does not go to the DB often, but the id's generated by it can clash with those generated by other applications if they follow the DB sequence.
> In our applications, we have an Oracle sequence with increment 50 for each table - we would want all inserts into a table to pick the ID from the corresponding sequence.
> I am submitting a patch with an ID generator which accomplishes this.
--
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, 5 months