3 Oct
2012
3 Oct
'12
11:09 a.m.
Hi Denis
On Oct 3, 2012, at 10:55 AM, Denis Gervalle <dgl(a)softec.lu> wrote:
[snip]
IMO, we should avoid pursuing with hacks over our
Hibernate implementation.
I am more in favor to remove our current, really underused custom solution,
which is really expensive in maintenance compare the their real usage. In
comparison, your proposal seem more clean, and a bit less dynamic. I do not
think going too far and being too smart to be dynamic is really important.
Providing extension a way to register their hibernate mapping, and at some
point during wiki startup, building the hibernate session factory in a
single step would be the cleanest and most efficient solution. When one or
some new extensions are installed, and one or some of these extensions have
registered an additional hibernate mapping, rebuilding the session factory
once at the end of the installation would probably be the best.
In regards to your proposal, if I well understand it, I am not sure the way
you expect to chain the call to the configure() method is nice. It will
implies that order could matter. While this would allow the ability to
modify a configuration previously made, you will have no way to ensure such
configuration has been made before. So there is no point to provide
the aggregated configuration, unless you may ensure ordering. Maybe I have
overlooked something ?
Let me explain, we have a chicken and egg issue :)
We need to pass to HibernateConfiguration the DB we're on (mysql, oracle, etc) so that
they can return mappings for a given DB (when the mappings are different between various
DBs).
Since the DB used is defined in the Hibernate configuration itself there are only 2 ways
to do this:
* Solution 1: have a first pass to create a Configuration by loading only basic properties
(no mapping) and then build a session factory and from there get a connection from the
connection provider and then call getMeta() to get a DatabaseMetaData instance. Then we
can pass it to the mapping configuration components. The problem with this approach is
that we need to build the session factory twice.
* Solution 2: Extract the DB used by getting it from the connection url which is always of
the form: jdbc:<dbtype>:<something>. For this to work we need to be sure that
the property defining the connection url is passed first. This is why I've introduced
an order and I'll put the main "xwiki" HibernateConfiguration with a high
priority so that it loads first.
I've chosen solution 2 which seems the best to me and allows other things:
* The ability to not only pass mappings but also contribute other hibernate configuration
properties should it be needed
* The ability for a given configuration to know what has been set and decide what it does
based on that.
FYI right now my local implementation has:
@Role
public interface HibernateConfiguration extends Comparable<HibernateConfiguration>
{
void configure(Configuration aggregatedConfiguration);
int getPriority();
}
Thanks
-Vincent