On 4 Mar 2007, at 19:57, Galder Zamarreno wrote:
I've got this working, including some basic unit tests and manual
examples to transform entired cache stores from 1.x data to 2.x.
These last manual examples include source code, 1.x cache stores
(file and jdbc derby db) and sample cache configurations.
Apart from the MV issue referred earlier, I have realised that
TransformingJDBCCacheLoader will have to extend JDBCCacheLoaderOld
instead of JDBCCacheLoader.
The reason is because when JDBCCacheLoader starts, if the root does
not exist, it'll create it, which in the
TransformingJDBCCacheLoader will mean creating it in 2.x format.
This wouldn't be a problem if the root node didn't need querying
again, but if customers want to migrate their data, they will start
looping from the node (cache.getRoot()) and the first thing they'll
get its children. This results in trying to load the root node from
the cache store which breaks, as we're reading from db in 1.x format.
Remember that the TransformingJDBCCacheLoader reads in 1.x format
and stores in 2.x format.
This has a very easy resolution which is extending
JDBCCacheLoaderOld. After that, it works like a treat :).
Manik, assuming you're happy with the original idea, would
extending JDBCCacheLoaderOld for this one off cache loader be ok
with you?
Yes, this makes sense, provided:
1) These "utilities" are in a separate package and perhaps even a
separate jar? o.j.c.loader.migration.*?
2) Even JDBCCacheLoaderOld (should be renamed to
LegacyJDBCCacheLoader or something? Mircea?) should be in this
"migration" package. I don't see anyone using it on an ongoing basis.
WDYT?
Cheers,
Manik