Re: [hibernate-dev] User defined generic bag
Hi, the list you posted to is for Java Hibernate. You probably wanted to post to the NHibernate development list. Its address is [EMAIL PROTECTED] To answer your question, yes, please submit the patch to our JIRA (http://jira.nhibernate.org), we will then review it and decide whether to apply it. Thanks, Sergey phi wrote: Hi, NHibernate 1.2 always returns an PersistentGenericBag for an association marked as Bag. For a project we are currently working on, we needed support for our own List implementation. NHibernate already supports an attribute collection-type on bags, but for generic collections this is ignored. I patched NHibernate to take into account for user defined collections and would like to ask if there is any interest in merging this into the official NHibernate code. What I did: .) Modified TypeFactory.CustomCollection to accept an additional System.Type[] genericArguments parameter. .) Modified NHibernate.Mapping.Collection.CustomCollection to call the aforementioned method. So by implementing IPersistentCollection and providing a custom Type the extends BagType one can easily provide its own persistent list. Currently, I only did this for associations that use bag semantics but I think this could be enhanced pretty well. If there is any interest please drop my a line and give me directions where to put the code (JIRA?). Cheers, phi ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [NHibernate-development] [hibernate-dev] Connection release modes
Steve Ebersole wrote: I don't understand the statement about auto-commit mode connection release. The idea with the implied auto-commit connection release mode is that in the case of auto-commit transaction control, there is really no need to have the same connection for each operation as long as we are not batching and not generally holding open JDBC resources. What makes you say it appears to happen for just a few operations? I guess I worded that badly. To put it in source code terms: in SessionImpl.get(String entityName, Serializable id) there is a call to SessionImpl.afterOperation. There is no such call in SessionImpl.get(String entityName, Serializable id, LockMode lockMode). Is this a mistake or is the call not needed in the second case for some reason? Sergey ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [NHibernate-development] [hibernate-dev] Connection release modes
Steve Ebersole wrote: How did that lead to a discussion of connection release modes ;) Err, it was the other way around :) a discussion of connection release modes led to this. I'm trying to understand what the code does in Hibernate to be able to port it to NHibernate. Mmm, I'd have to look through the code; *but* a load lock operation makes no sense in an auto-commit scenario; so I'd assume it has to do with that... Does refresh(Object) make sense in auto-commit? It doesn't call afterOperation either. Sergey ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
