[hibernate-dev] Adding fetch joins to HQL queries programatically
Hi, I would like to be able to extend the functionality of org.hibernate.Query in two ways: 1. Have a method on Query that returns the result aliases and their position in the resulting object array. I think this information is already available at the QueryImpl level, but just not exposed through the public Query interface. Right now, if you do not use the AliasToMapResultTransformer this information cannot be accessed. 2. Being able to add fetch joins programmatically for a given alias. This is possible through straight hacking of the Hibernate code (I found the cleanest place to add the fetch join was in QueryLoader, but it could be done at the AST level too). I would like to do able to do this without resorting hacking Hibernate directly, but instead through a public API or extension point. Of course I could parse the HQL directly, but that is very ugly. Both of these points are already available in Criteria. Regards, Ali Ibrahim Autofetch: http://www.cs.utexas.edu/~aibrahim/autofetch ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Hibernate extension points
Hi, Sorry about being presumptuous there. I think there are only 3 external classes, plus a bunch of inner classes which refer to HbmBinder. The inner classes could be converted to non-static inner classes and we would just have to pass an instance of HbmBinder to the 3 external classes that use it. Shouldn't be too bad. Regards, Ali Ibrahim Emmanuel Bernard wrote: 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
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
[hibernate-dev] Hibernate extension points
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