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
[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
[hibernate-dev] [Search] Adding more functionality to ScopedAnalyzer
Hi there,
I would like to extend ScopeAnalyzer so that I can specify an analyzer
for some extra fields that my custom bridge is writing into the index.
I don't (and can't really) create dummy accessors in my class for
these as their names are based on database data.
For example imagine we wanted to search for staff by their department,
so our field name might be:
people.sales
people.customerservice
Assume these departments would come from the DB and wouldn't be hard
coded into code, and require a custom analyzer.
In order to support specifying a custom analyzer for these records
there would need to be a way of specifying a wildcard in the
ScopeAnalyzer that would match "people.*".
This is a feature I need, and something which may be needed in the
future. I'm happy to develop a patch for it.
The way I would propose to approach this is:
1) Make ScopedAnalyzer match wildcards, which could be done by holding
a second map of analyzers, sorted by key longest first, and if an
analyzer cannot be found directly for a given field wilcard matches
can be checked. If a match is found it can be explicitly populated in
the direct cache for immediate lookup. If there is a miss then the
default analyzer can be inserted, saving further wildcard tests.
Performance penalty would be minimal.
2) Configure ScopedAnalyzer with the wildcards.
I can see two approaches to doing this:
a) Create a new class level annotation @AnalyzerBindings that takes
something like
@AnalyzerBindings({
@AnalyzerBinding(pattern="person.department.*", impl=MyAnalyzer.class)
})
Configure this from DocumentBuilder when the class is setup.
b) Create a callback or other mechanism that allows custom bridges to
specify which patterns they would like to match. I'd suggest a method
like
Maphttps://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [Search] Adding more functionality to ScopedAnalyzer
I think there are 2 separate problems here.
You want wildcard resolution. I am not entirely sure why. Is it
because your custom FieldBridge create a lot of fields in the document?
How are the fields indexed exactly? Using @Field/@FieldBridge or
@ClassBridge
Both support the use of Analyzer, can you tell me why your model does
not fit in it?
Emmanuel
On Feb 29, 2008, at 12:04, Nick Vincent wrote:
Hi there,
I would like to extend ScopeAnalyzer so that I can specify an analyzer
for some extra fields that my custom bridge is writing into the index.
I don't (and can't really) create dummy accessors in my class for
these as their names are based on database data.
For example imagine we wanted to search for staff by their department,
so our field name might be:
people.sales
people.customerservice
Assume these departments would come from the DB and wouldn't be hard
coded into code, and require a custom analyzer.
In order to support specifying a custom analyzer for these records
there would need to be a way of specifying a wildcard in the
ScopeAnalyzer that would match "people.*".
This is a feature I need, and something which may be needed in the
future. I'm happy to develop a patch for it.
The way I would propose to approach this is:
1) Make ScopedAnalyzer match wildcards, which could be done by holding
a second map of analyzers, sorted by key longest first, and if an
analyzer cannot be found directly for a given field wilcard matches
can be checked. If a match is found it can be explicitly populated in
the direct cache for immediate lookup. If there is a miss then the
default analyzer can be inserted, saving further wildcard tests.
Performance penalty would be minimal.
2) Configure ScopedAnalyzer with the wildcards.
I can see two approaches to doing this:
a) Create a new class level annotation @AnalyzerBindings that takes
something like
@AnalyzerBindings({
@AnalyzerBinding(pattern="person.department.*",
impl=MyAnalyzer.class)
})
Configure this from DocumentBuilder when the class is setup.
b) Create a callback or other mechanism that allows custom bridges to
specify which patterns they would like to match. I'd suggest a method
like
Maphttps://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
