migrating out of elgg 09 to 1x in an odd manner

Sun, Mar 8, 2009

With the upcoming release of Elgg 1.5, there’s been talk of the migration plugin, or rather its absence, after it was scheduled for release with 1.5. That means there’s no easy way to get out of what seems to be a deprecated 0.9 Elgg product. A bit frustrating when you can peek over the wall and see all that shiny new API and architecture but there doesn’t seem to be a way to get over the wall. So I decided to bite the bullet and delve into the murky world of migration, Elgg 0.9 style.

The first problem I found was that 1.5 doesn’t support the concept of communities and considering this is basis of 0.9, that’s a pretty big problem. In more ways than one, 1.x is a completely different product from 0.9. It’s not too bad though, as 1.5 seems to use groups as communities. It’s just as weird in 0.9 though as it uses users as communities. In the best traditions of Spike Milligan and The Bed Sitting Room, users in Elgg have transmogrified from humans into buildings!

The next major problem is 1.5 does not support folders, so the file structure in 0.9 will have to be flattened.

So how to go about the migration? It’s a bit like painting a masterpiece, layer by layer. First, the users will need to be shifted, to provide the base data layer, then groups will have to be built up from the community information in 0.9. That will give me an ownership basis for when I migrate the files, blog posts, tags and comment wall posts. Lastly, the friends network can be layered on top of the users and groups. For groups (i.e. communities), the comment wall posts from 0.9 can be used as the message board posts and the tags can be bunged across too. So it shouldn’t be too difficult but how best to do it?

Apparently 1.x is making noises about the Open Data Definition (OpenDD), which is yet another, albeit cut-down, data interchange format. It’s not very concise but it’s not meant for human consumption, even though it’s XML based. So I’ve decided to export the 0.9 data in ODD format. It’s basically a lot of database drudgery, working out how each bit is related to the other but I’ve come up with a strategy for migrating communities and as I need an element of personal improvement, I’ve done it in Ruby. Welcome oddbod!

Oddbod is a ruby app that will export 0.9 data in various batches, which I’ve called Bods, as defined above. I’ve completed the user Bod and an example ODD output is:

<odd version=“1.0”>
  <entity uuid=‘https://communities.uhi.ac.uk/oddbod/person/1' class=‘person’/>
  <entity uuid=‘https://communities.uhi.ac.uk/oddbod/person/2' class=‘person’/>
  <entity uuid=‘https://communities.uhi.ac.uk/oddbod/person/3' class=‘person’/>

  <metadata uuid=” entity_uuid=‘https://communities.uhi.ac.uk/oddbod/person/1' Name=‘username’>     news   </metadata>   <metadata uuid=” entity_uuid=‘https://communities.uhi.ac.uk/oddbod/person/1' Name=‘name’>     News   </metadata>   <metadata uuid=” entity_uuid=‘https://communities.uhi.ac.uk/oddbod/person/1' Name=‘active’>     yes   </metadata> </odd>

ODD is basically a sequential stream of data. It doesn’t have to be in order of definition but they recommend you do that, in case it gets delivered in some weird order to the client. entity elements define the base classes if you like, while metadata elements fill out the details of those classes. What you see in the above fragment is the News user and two others, with some metadata being defined for the News user. I haven’t bothered with metadata uuids just now as it just clutters the show.

Community (group in 1.5) memberships are expressed as relationships in ODD:

<relationship uuid_one=“https://communities.uhi.ac.uk/oddbod/person/1"
                        uuid_two=“https://communities.uhi.ac.uk/oddbod/community/24" />
similarly, a comment wall post can be associated with a community thus:
<relationship uuid_one=“1930” type=“commentwallpostof”
                         uuid_two=“https://communities.uhi.ac.uk/oddbod/community/24" />
and a community blog is:
<relationship uuid_one=“24-blog” type=“ownedby”
                        uuid_two=“https://communities.uhi.ac.uk/oddbod/community/24" />
How do I know this? Because I say so! I’ve basically defined an ODD profile, for migrating 0.9 to 1.5. Tentative name for the profile is the Oddbod Profile. I’ll also need to do a 1.5 plugin that can consume ODD in general and the Oddbod profile in particular, as it will need to understand the types and classes I’ve defined in the sample ODD.

So the base user and community data can be migrated first, followed by ODD Bods of relationships. The only major problem is the lack of a file hierarchy in 1.5, so I can’t migrate the folders. I’ll just have to flatten everything, which is what eventually happened to The Bed Sitting Room!

comments powered by Disqus