This was for hibernate-tools.
On Feb 19, 2008 10:07 AM, Tomislav Stojcevich <stojcevicht(a)gmail.com> wrote:
> Was a tag created for this release? The closest I can find is CR1, I
> need the sources to the GA release.
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:
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
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
Map<String, Analyzer) getCustomAnalyzers ()
could be added to the Bridge interface (or another interface to avoid
breaking changes) which could be called when the bridges are
configured in DocumentBuilder.
Any feedback on either approach is much appreciated.
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.
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
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.
I have been trying to build trunk for the past several days and the
instructions that I have found don't appear to be current (they refer to
using Ant even though there have been recent discussions on this list
referring to maven).
Is there a more current doc that .../268 ?
Or, if there is not - could someone give me full directions for building
Hibernate trunk from a clean start?