[hibernate-dev] Hudson build is back to normal: hibe rnate-3.2 » mssql-jtds,linux-slim #77
See http://hudson.qa.jboss.com/hudson/job/hibernate-3.2/./TEST_DATABASE=mssql-jtds,label=linux-slim/77/changes ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Hudson build is back to normal: hibe rnate-3.2 » mssql-msjdbc,linux-slim #77
See http://hudson.qa.jboss.com/hudson/job/hibernate-3.2/./TEST_DATABASE=mssql-msjdbc,label=linux-slim/77/changes ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Hudson build is back to normal: hibe rnate-3.2 » mysql50,linux-slim #77
See http://hudson.qa.jboss.com/hudson/job/hibernate-3.2/./TEST_DATABASE=mysql50,label=linux-slim/77/changes ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Hudson build became unstable: hibern ate-3.2 » oracle10g,linux-slim #77
See http://hudson.qa.jboss.com/hudson/job/hibernate-3.2/./TEST_DATABASE=oracle10g,label=linux-slim/77/changes ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Hibernate extension points
Nice work Can you open a JIRA issue for each point (forget #6 though, too much work) and explain the reason for the need briefly? Emmanuel On Feb 26, 2008, at 14:10, Ali H. Ibrahim wrote: Hi, I have been working on an extension to Hibernate called Autofetch. I ran into some pain points and although I have worked around them for now, I was wondering which of these I could help make better either through patches or JIRA issues. Most of these are pretty selfish in that they would have made my life easier by making more code accessible. 1. AbstractLazyInitializer has the initialize method as final. It can be useful to be able to override that method to do stuff. I realize it is important to make sure that the method is eventually called. 2. AbstractPersistentCollection has read and write methods as final. Again, it was useful in my extension to be able to override these methods. 3. DefaultInitializeCollectionListener has initializeCollectionFromCache method as private. When I subclassed the DefaultInitializeCollectionListener I would have like to have been able to call this method from my subclass instead of copying the code. 4. The PojoInstantiator's state is all private with no getters. It would have nice to be able to subclass it in a meaningful way. 5. A generally useful class is a delegate interceptor which takes takes an interceptor as a constructor argument and by default dispatches requests to that interceptor. 6. Might be nice for HbmBinder not to be a static class. 7. Right now, the tuplizer extension point allows for very broad changes in how entities are instantiated, proxies, etc. However there is no such extension point for the PersistentCollection classes. I know you can change the underlying collection behavior, but I need to change the behavior of the collection classes before the underlying collection is instantiated. Shameless plug for Autofetch: http://www.cs.utexas.edu/~aibrahim/autofetch. Basically Autofetch tries to automate association fetches for queries, with the goal of eliminating the need for programmer provided fetch annotations either in the configuration file or in the queries themselves. It does so by monitoring a programs traversals and learning the correct fetch profile for each class of queries. It differentiates queries not only using the query itself, but also the stack trace so that different invocations of method containing a query will be treated differently. Regards, Ali Ibrahim ___ 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: [hibernate-dev] Hibernate extension points
Hi, I have opened some JIRA improvement issues for the points below. I assumed you meant forget #7 as that seems to be one that requires a lot of work. I mistakenly marked one of the issues as major when I meant minor, but it seems I don't have permission to fix that. Regards, Ali Emmanuel Bernard wrote: Nice work Can you open a JIRA issue for each point (forget #6 though, too much work) and explain the reason for the need briefly? Emmanuel On Feb 26, 2008, at 14:10, Ali H. Ibrahim wrote: Hi, I have been working on an extension to Hibernate called Autofetch. I ran into some pain points and although I have worked around them for now, I was wondering which of these I could help make better either through patches or JIRA issues. Most of these are pretty selfish in that they would have made my life easier by making more code accessible. 1. AbstractLazyInitializer has the initialize method as final. It can be useful to be able to override that method to do stuff. I realize it is important to make sure that the method is eventually called. 2. AbstractPersistentCollection has read and write methods as final. Again, it was useful in my extension to be able to override these methods. 3. DefaultInitializeCollectionListener has initializeCollectionFromCache method as private. When I subclassed the DefaultInitializeCollectionListener I would have like to have been able to call this method from my subclass instead of copying the code. 4. The PojoInstantiator's state is all private with no getters. It would have nice to be able to subclass it in a meaningful way. 5. A generally useful class is a delegate interceptor which takes takes an interceptor as a constructor argument and by default dispatches requests to that interceptor. 6. Might be nice for HbmBinder not to be a static class. 7. Right now, the tuplizer extension point allows for very broad changes in how entities are instantiated, proxies, etc. However there is no such extension point for the PersistentCollection classes. I know you can change the underlying collection behavior, but I need to change the behavior of the collection classes before the underlying collection is instantiated. Shameless plug for Autofetch: http://www.cs.utexas.edu/~aibrahim/autofetch. Basically Autofetch tries to automate association fetches for queries, with the goal of eliminating the need for programmer provided fetch annotations either in the configuration file or in the queries themselves. It does so by monitoring a programs traversals and learning the correct fetch profile for each class of queries. It differentiates queries not only using the query itself, but also the stack trace so that different invocations of method containing a query will be treated differently. Regards, Ali Ibrahim ___ 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: [hibernate-dev] Hibernate extension points
I mean 6. HBMBinder is essentially static, there is no real way around that without rewriting a lot of boring code. On Feb 28, 2008, at 17:26, Ali H. Ibrahim wrote: Hi, I have opened some JIRA improvement issues for the points below. I assumed you meant forget #7 as that seems to be one that requires a lot of work. I mistakenly marked one of the issues as major when I meant minor, but it seems I don't have permission to fix that. Regards, Ali Emmanuel Bernard wrote: Nice work Can you open a JIRA issue for each point (forget #6 though, too much work) and explain the reason for the need briefly? Emmanuel On Feb 26, 2008, at 14:10, Ali H. Ibrahim wrote: Hi, I have been working on an extension to Hibernate called Autofetch. I ran into some pain points and although I have worked around them for now, I was wondering which of these I could help make better either through patches or JIRA issues. Most of these are pretty selfish in that they would have made my life easier by making more code accessible. 1. AbstractLazyInitializer has the initialize method as final. It can be useful to be able to override that method to do stuff. I realize it is important to make sure that the method is eventually called. 2. AbstractPersistentCollection has read and write methods as final. Again, it was useful in my extension to be able to override these methods. 3. DefaultInitializeCollectionListener has initializeCollectionFromCache method as private. When I subclassed the DefaultInitializeCollectionListener I would have like to have been able to call this method from my subclass instead of copying the code. 4. The PojoInstantiator's state is all private with no getters. It would have nice to be able to subclass it in a meaningful way. 5. A generally useful class is a delegate interceptor which takes takes an interceptor as a constructor argument and by default dispatches requests to that interceptor. 6. Might be nice for HbmBinder not to be a static class. 7. Right now, the tuplizer extension point allows for very broad changes in how entities are instantiated, proxies, etc. However there is no such extension point for the PersistentCollection classes. I know you can change the underlying collection behavior, but I need to change the behavior of the collection classes before the underlying collection is instantiated. Shameless plug for Autofetch: http://www.cs.utexas.edu/~aibrahim/autofetch. Basically Autofetch tries to automate association fetches for queries, with the goal of eliminating the need for programmer provided fetch annotations either in the configuration file or in the queries themselves. It does so by monitoring a programs traversals and learning the correct fetch profile for each class of queries. It differentiates queries not only using the query itself, but also the stack trace so that different invocations of method containing a query will be treated differently. Regards, Ali Ibrahim ___ 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
