[Hibernate-JIRA] Commented: (ANN-9) Support interface inheritance mapping
by Barney Boisvert (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/ANN-9?page=comm... ]
Barney Boisvert commented on ANN-9:
-----------------------------------
Pascal,
Yeah, it's kind of annoying. Note that you only have to map the interface if you need Hibernate to be aware of it. You can still use the interfaces in your code and only tell Hibernate about the implementations. Not suitable for all cases, of course, and it puts a cramp on doing polymorphic queries (HQL or otherwise) when Hibernate's not aware of the interface, but it can let you use more annotations. Another option would to annotate your interfaces, and then use APT to postprocess all your annotations in *.hbm.xml files automatically, but that's probably quite a bit more work than it's worth.
> Support interface inheritance mapping
> -------------------------------------
>
> Key: ANN-9
> URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-9
> Project: Hibernate Annotations
> Type: Improvement
> Components: binder
> Versions: 3.1beta3
> Reporter: Gili
> Attachments: hibernate3-annotations-3.1beta5-3896-3948.diff, hibernate3-annotations-3.1beta5-3896-4138.diff
>
>
> It should be possible to create a mapping with interfaces, as described by the documentation here: http://www.hibernate.org/hib_docs/v3/reference/en/html_single/#inheritanc...
> Specifically right now it is impossible to annotate interfaces and according to HBX-231 even if you could @Entity is only meant to get used on classes so the question becomes "what do you annotate it with?"
> As I pointed out here http://forum.hibernate.org/viewtopic.php?p=2238824#2238824 the additional problem seems to be that XDoclet doesn't support interface annotation either (http://opensource.atlassian.com/projects/xdoclet/browse/XDT-1345) so I'm left without a workaround.
> I can't convert the interfaces to abstract classes because I implement multiple interfaces in my application and Java does not do multiple inheritance.
> If you know of a nice workaround, please let me know :)
--
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
17 years, 8 months
[Hibernate-JIRA] Created: (HHH-2485) The PersistentSet recognized as dirty because the PersistentSet.getSnapshot method uses wrong object as key for clonedSet
by Csaba Krizsan (JIRA)
The PersistentSet recognized as dirty because the PersistentSet.getSnapshot method uses wrong object as key for clonedSet
-------------------------------------------------------------------------------------------------------------------------
Key: HHH-2485
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2485
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.2
Environment: Hibernate version 3.x HSQLDB (db platform independent bug)
Reporter: Csaba Krizsan
Attachments: hibernate-persistentset-test.zip
The org.hibernate.collection.PersisitentSet.getSnapshot method uses the copied object as key in clonedSet therefore the equalsSnapshot method does not find the copied object in clonedSet (it uses the original object as key)
public Serializable getSnapshot(CollectionPersister persister)
throws HibernateException {
EntityMode entityMode = getSession().getEntityMode();
//if (set==null) return new Set(session);
HashMap clonedSet = new HashMap( set.size() );
Iterator iter = set.iterator();
while ( iter.hasNext() ) {
Object copied = persister.getElementType()
.deepCopy( iter.next(), entityMode, persister.getFactory() );
clonedSet.put(copied, copied); // <--- BUG The key should be the object returned by iter.next()
}
return clonedSet;
}
Please fix it using the original object as key during adding the copied object into clonedSet.
I have attached a test, which creates a parent-child relation which uses <set>.
The testGet method loads the records, prints them and calls session.flush().
The flush() recognizes that the set is dirty because of the aforementioned bug.
In the settest.log file you can see that the set gets dirty during flush.
10:50:55,187 [main] DEBUG .AbstractFlushingEventListener - flushing session
10:50:55,187 [main] DEBUG .AbstractFlushingEventListener - processing flush-time cascades
10:50:55,187 [main] DEBUG .AbstractFlushingEventListener - dirty checking collections
10:50:55,187 [main] DEBUG engine.CollectionEntry - Collection dirty: [com.webage.test.hibernate.Parent.children#1]
Please fix it
Thanks in advance
--
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
17 years, 8 months
[Hibernate-JIRA] Commented: (HBX-706) Hibernate ant task does not work in a multi-project Maven 2 build if other mojos use javax.xml.transform
by Brill Pappin (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-706?page=co... ]
Brill Pappin commented on HBX-706:
----------------------------------
This issue still exists using hibernate 3.2.2.ga
> Hibernate ant task does not work in a multi-project Maven 2 build if other mojos use javax.xml.transform
> --------------------------------------------------------------------------------------------------------
>
> Key: HBX-706
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-706
> Project: Hibernate Tools
> Type: Bug
> Components: ant
> Versions: 3.1beta4
> Environment: Hibernate 3.1, database is Oracle (but not relevant to this)
> Reporter: Alfie Kirkpatrick
> Fix For: 3.2beta7
> Attachments: hibernate-problem.zip
>
>
> I have a reasonably complex maven 2 build with multiple projects. More than one of the projects uses the hbm2java task and at least one of the projects uses the Codehaus xslt-maven-plugin. When running the project that uses both hbm2java and XSLT, it works fine. But running the master build throws the following error.
> org.apache.maven.lifecycle.LifecycleExecutionException: Error executing ant tasks
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
> [snip]
> Caused by: java.lang.IllegalStateException: 3.1.0.beta4 found when setting version
> at org.hibernate.tool.hbm2x.TemplateHelper.putInContext(TemplateHelper.java:223)
> [snip]
> I can't really explain where this error is coming from. I looked at the source for putInContext and it is using the Plexus options class and failing because the value of "version" is already in the options.
> I assumed from this it was a problem with the xstl-maven-plugin from Codehaus also using some Plexus libraries, but I refactored the mojo so it was ONLY using javax.xml.transform and the problem remained.
> I then changed my slimmed down mojo to force use of Saxon instead of the default JAXP implementation (Xalan?).
> .. and it worked fine!
> So this is definitely a problem with the instantiation of the default XSLT functionality in JDK1.4, although how that can possibly affect the build in this way is beyond me.
> You might consider this a Maven bug but it's very strange that it doesn't happen for any old mojo combination. I also think it is probably much easier to fix in Hibernate tools than in Maven.
> I'd suggest a couple of possible fixes/improvements:
> - Make "version" key more specific, eg. hibernate.tools.version to avoid possible clash with other Plexus clients in the same JVM
> - Don't throw an exception on any existing value being set as it is now but compare the value in the options to the new value and only throw an exception if they differ
> I can't think of a way to track down the underlying cause of this issue. It's a very odd one.
> Attached is a simple three project build to reproduce the problem. Just run 'mvn clean package' on the parent project to reproduce.
--
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
17 years, 8 months
[Hibernate-JIRA] Created: (ANN-531) EntityMode.DOM4J does not deserialize collection entities
by Laurent Perez (JIRA)
EntityMode.DOM4J does not deserialize collection entities
---------------------------------------------------------
Key: ANN-531
URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-531
Project: Hibernate Annotations
Type: Bug
Components: binder
Versions: 3.2.2
Environment: PATCH ANN-517 APPLIED (see http://opensource.atlassian.com/projects/hibernate/browse/ANN-517), revision 11026.
Reporter: Laurent Perez
The XML deserialization of an entity does not deserializes its child properties but only its id, following sample :
Foobean are children of a Screen :
@Entity
@Table (name="foobean")
public class Foobean implements java.io.Serializable {
private String name;
private String age;
private Screen screen;
@Id
@Column(name="name")
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
@ManyToOne
public Screen getScreen() {
return this.screen;
}
public void setScreen(Screen screen) {
this.screen = screen;
}
@Column(name="age")
public String getAge() {
return age;
}
public void setAge(String age) {
this.age = age;
}
}
Relevant parent Screen annotations :
private Set<Foobean> fooBeans = new HashSet<Foobean>();
@OneToMany(cascade=CascadeType.ALL, fetch=FetchType.EAGER)
public Set<Foobean> getFoobeans(){
return this.fooBeans;
}
public void setFoobeans(Set<Foobean> fooBeans) {
this.fooBeans = fooBeans;
}
Association :
Foobean foobean = new Foobean();
foobean.setName("foo");
foobean.setAge("age");
foobean.setScreen(screen);
screen.getFoobeans().add(foobean);
Generated XML (the age property of Foobean is missing, i.e there is no <name>foo</name><age>age</age>) :
<Screen>
<id>1</id>
<foobeans>
<Foobean>foo</Foobean>
</foobeans>
</Screen>
--
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
17 years, 8 months