Spring XML Namespace support for embedded-database and initialize - how simple is this...
Neale Upstone
(https://github.com/whirlwind-match/whirlwind-db/issues/milestones) is
progressing well.
Having provided the ability to boot an embedded database without the
need for TCP/IP transport in M1, this has now been brought up to the
expectations of regular Spring users to mimic what they can do with JDBC
access to H2, HSQL and Derby.
For a fuzzy database instance, we can now get a database booted, and
initialised with matching configurations with:
<fuzzy:embedded-database />
<fuzzy:initialize match-styles="classpath:propertyMatchingConfig.xml" />
<fuzzy:embedded-database /> creates a database instance, and an in
memory connection to it and exposes this by default as a bean named
'store'. This default is used wherever a reference to the store could
be provided, as generally only one instance is needed.
If you take a look at ExampleSpringTxTest, you'll see some usage
scenarios which certainly need expanding.
What's next is to simplify transaction management configuration.
Currently the following is needed to expose the rest of what's needed
for the above example:
<bean id="transactionManager" class="com.wwm.db.spring.transaction.WhirlwindPlatformTransactionManager">
<constructor-arg ref="store"/>
</bean>
<tx:annotation-driven mode="aspectj" transaction-manager="transactionManager"/>
<bean id="dataOperations" class="com.wwm.db.internal.CurrentTransactionDataOperationsProxy">
<constructor-arg ref="store"/>
</bean>
I see no reason to make transaction management require lots of config
when 90% will need the same defaults, so I think we should be able to
achieve the following:
- Automatically create an appropriate transaction manager for 'store' if
no transactionManager bean is found.
- Allow manual creation using <fuzzy:tx-manager id="transactionManager"
store="store" /> with these values being the defaults if omitted (i.e.
<fuzzy:tx-manager /> is enough)
The loose end is now DataOperations, which implements our existing API.
With Spring Data Commons providing the basics for a Repository
abstraction, and a mapping framework, then there is work to be done in
this area...
Watch this space for updates, and naturally check the status at github.