Hi Denis
On Oct 3, 2012, at 10:55 AM, Denis Gervalle <[email protected]> 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
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
