jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robin Wyles <ro...@jacaranda.co.uk>
Subject Re: Problems migrating from 1.6.0 to 2.1.0
Date Fri, 27 Aug 2010 15:03:53 GMT
Hi Stefan

On 27 Aug 2010, at 13:11, Stefan Guggisberg wrote:

> On Fri, Aug 27, 2010 at 2:02 PM, Stefan Guggisberg
> <stefan.guggisberg@day.com> wrote:
>> On Fri, Aug 27, 2010 at 1:18 PM, Robin Wyles <robin@jacaranda.co.uk> 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 <robin@jacaranda.co.uk>
>>>>> 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...

Both mysql instances use the same charset/encoding, and all tables on both instances are set
to utf-8 for encoding and collation. 

The only difference between the two mysql instances are their version - slightly older on
our production machine.  

However, what you say makes sense - it really does look like Jackrabbit can't find those nodes
on start up which implies there's a charset/encoding issue. 

I'm going to see if I can duplicate the database on our production mysql instance and test
against that...

> or maybe it's a problem with the mysql indexes on those tables...

I tried deleting the mysql indexes and recreating them, it didn't seem to make any difference.



View raw message