On Fri, Aug 27, 2010 at 1:18 PM, Robin Wyles <[email protected]> wrote: > Hi Stefan, > > Thanks for your quick reply... > > On 27 Aug 2010, at 11:36, Stefan Guggisberg wrote: > >> hi robin, >> >> On Fri, Aug 27, 2010 at 11:25 AM, Robin Wyles <[email protected]> wrote: >>> Hi, >>> >>> I'm having problems migrating an existing repository from Jackrabbit 1.6.0 >>> to 2.1.0. >>> >>> Here are the steps I followed to test the migration: >>> >>> 1. Update app to use Jackrabbit 2.1.0, run unit tests etc. Manually test >>> against empty 2.1.0 repository. All works fine here. Our repository >>> configuration has not changed at all between versions. >>> >>> 2. Used mysqldump to export production repository. >>> >>> 3. Copy production repository directory (workspace folder, datastore, index >>> folders etc.) to test machine. >>> >>> 4. Import SQL file from 2 above to new DB on test machine. >>> >>> 5. Start application on test machine. >>> >>> The result of the above is that the application starts up without error but >>> that the repository appears empty. I am able to add new nodes to the >>> repository, which behave correctly within the application yet none of the >>> existing nodes are visible. I've tried xpath queries against known paths, >>> e.g. "//library/*" and these return 0 nodes. >>> >>> A few things I've tried/noticed: >>> >>> 1. Repeating steps 3 and 4 above, then removing the old index directories >>> before starting the application. Jackrabbit creates new lucene indexes, but >>> they are very small, just like they would be when initialising an empty >>> repository. Also, the index files are called indexes_2 rather than indexes >>> as they were under 1.6.0. >>> >>> 2. When starting the app after the migration I notice that 4 extra records >>> have been added to the BUNDLE table, 3 extra records are added to the >>> VERSION_BUNDLE table and 2 extra records added to the VERSION_NAMES table. >>> Again, this seems to be consistent with what is added automatically added >>> to the database when a new repository is initialised. >>> >>> So, basically it appears that Jackrabbit is completely ignoring the >>> existing repository data, and instead initialising a new repos using the >>> existing database… >>> >>> If anyone has any ideas as to how I can get 2.1.0 to recognise our existing >>> repository they'd be gratefully received - I feel there must be something >>> simple I've overlooked! >> >> hmm, seems like the key values (i.e. the id format) has changed. >> however, i am not aware of such a change. >> maybe someone else knows more? > > The release notes for Jackrabbit 2.0.0 claim that it is backward compatible > with 1.x repositories. I've seen a couple of messages on the users list > relating to migration issues but these seem to involve custom nodetypes, > whereas our repository has no custom nodetypes. > > How may I see what key values/ID format is used by the different versions? > This sounds like quite a major change to me, and I'm sure something that > would've been documented!
absolutely. however, if you're saying that 4 extra records have been inserted into the BUNDLE table and the BUNDLE table already had n>=4 records, i can only explain it with a changed binary representation of the record id's. the 4 BUNDLE records are: / (root node) /jcr:system /jcr:system/jcr:nodeTypes /jcr:system/jcr:versionStore the values of the ids those nodes are hard-coded in jackrabbit. on startup, those nodes will be created if they don't exist. i am not a mysql expert. have you compared the configurations of both mysql instances? maybe it's some strange charset/encoding issue... cheers stefan > > Thanks, > > Robin > > > >
