On Fri, Aug 27, 2010 at 2:02 PM, Stefan Guggisberg <[email protected]> wrote: > 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...
or maybe it's a problem with the mysql indexes on those tables... cheers stefan > > cheers > stefan > > >> >> Thanks, >> >> Robin >> >> >> >> >
