jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Guggisberg <stefan.guggisb...@day.com>
Subject Re: Problems migrating from 1.6.0 to 2.1.0
Date Fri, 27 Aug 2010 12:11:14 GMT
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> 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
>>
>>
>>
>>
>

Mime
View raw message