I forgot to mention why I'm proposing this…
My goal is to be able to have a new module that brings a new mapping and for it to be
transparent for the users. ATM we can have modules bringing new mappings but the users
need to modify their existing hibernate.cfg.xml files and the majority won't do a
proper merge. So the idea is to remove the need for the merge.
Thanks
-Vincent
On Oct 2, 2012, at 8:53 PM, Vincent Massol <vincent(a)massol.net> wrote:
Hi devs,
I'd like to propose the following to implement
http://jira.xwiki.org/browse/XWIKI-8271:
* Create a new xwiki-platform-store-hibernate module
* Add a Component role: HibernateConfiguration implements Comparable
* API: void HibernateConfiguration.configure(Configuration aggregatedConfiguration),
where the passed aggregatedConfiguration contains the configuration filled by all the
HibernateConfiguration.configure() calls executed before
* Add a HibernateConfigurationManager.getConfiguration() component that is in charge of
loading the various HibernateConfiguration in the correct order
* Have an AbstractHibernateConfiguration implements HibernateConfiguration with 1 API:
getDatabaseType(Configuration configuration). It gets the DB type from the connection URL
string and returns a DatabaseType object which represents the database type
* CoreHibernateMapping (hint = "xwiki") <==> xwiki.hbm.*.xml - highest
priority, defines the connection URL among other props
* ActivityStreamHibernateMapping (hint = "activitystream")
* FeedHibernateMapping (hint = "feeds")
Note 1: If a HibernateConfiguration impl needs to load mappings that depend on the DB
they call AbstractHibernateConfiguration. getDatabaseType() to get the DB.
Note 2: If the user wants to use a different HBM file, he/she just has to put a file with
the same name (e.g. xwiki.hbm.xml) in WEB-INF/classes
Note 3: This means we won't put any mapping anymore in the hibernate.cfg.xml file
since it's not needed anymore (although it would continue to work if you put mappings
there).
Usage:
@Inject
HibernateConfigurationManager configurationManager;
Configuration configuration = configurationManager.getConfiguration();
SessionFactory sessionFactory = configuration.buildSessionFactory();
Then all that remains to implement
http://jira.xwiki.org/browse/XWIKI-8271 is to have a
component singleton that will be in charge of returning the SessionFactory and which can
be asked to rebuild a new SessionFactory (using a new Configuration).
We'll just need to decide how we trigger this. 2 options:
* By using an Event Listener listening on HibernateConfiguration registrations and
recreating automatically a new SessionFactory when it happens. Cons: if an extension
contributes several HibernateConfiguration then Hibernate will be reinitialized several
times
* By listening to an Event sent by the Extension Manager when an extension has finished
loading and somehow find out all the HibernateConfiguration that have been added (several
ways of doing this) and recreating the SessionFactory
Note: The only issue I can foresee is if a Hibernate call is in progress in one thread
when an extension is installed and a new SessionFactory is created at the same time.
Either we don't care or we could implement retry at the DB level, or we could
introduce some semaphore so that we start the reinit only when nobody has a lock on the
SessionFactory, or…
WDYT?
Of course, the pros is those listed in
http://jira.xwiki.org/browse/XWIKI-8271:
* Ability for a platform module to contribute Hibernate mappings (static)
* Ability for an extension installed at runtime to contribute Hibernate mappings
(dynamic)
Note that the reason I'm starting all this is because I'd like to implement
http://jira.xwiki.org/jira/browse/XWIKI-7953 cleanly in a module separate from oldcore.
Thanks
-Vincent