[hibernate-dev] Hibernate extension points

[Ali H. Ibrahim]

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 at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>