Wednesday, March 11, 2009

EMF on Server

I've been quiet for a while, mostly because of the mega refactoring that CDO is currently undergoing. Did you know that until now a CDO server did not have any dependencies on EMF? The following diagram summarizes what had been the status quo in this context for over two years:

As you can see, all EMF concepts had been converted to CDO concepts directly under the visible surface. It turned out that this approach had several drawbacks:
  • No generated EOperation logic on the server
  • No generated EDataType serialization
  • No EMF tools on the server (Compare, OCL, ...)
  • Backend integrators can not use EObject
  • Server extenders can not use EModelElement
So we decided to eliminate these restrictions by applying a two-step refactoring. The first step was to abandon CDOPackage completely and replace it with EPackage everywhere. This included replacements of CDOClass, CDOAttrbute and CDOReference as well. And CDOPackageManager was replaced by a new, very sophisticated version of CDOPackageRegistry. After one month of refactoring and testing the new status quo looks as follows:

In fact this was the biggest and most impacting refactoring since the complete re-write of version 0.7. Here are some numbers:
  • 69378 changed lines of code
  • 1736 changed files
  • 2.8 MB patch file size
  • 13% performance increase
The deployment of the new design will require re-creation of the backends, i.e. export data, re-create database, import data! Most clients will not be affected if they are properly coded against EMF APIs. The HibernateStore will be excluded from the builds for some time and then re-appear as a separate download to compensate p2 issues with missing, non-EPL dependencies.

Kudos go to Simon, who took over when I fell asleep, to Vik, who adjusted the UI and to Martin, who will adjust the HibernateStore. And apologies for the maintenance congestion that was caused by a locked HEAD.

After the merge to HEAD we'll be able to face the second step of the refactoring and make CDO-controlled EObjects available on the server:

This will open the door to some exciting new functionality on the server like:
  • Commit validation based on OCL
  • Common query based on OCL
  • Annotation-driven model mappings
  • Easier embedding into clients
Don't forget to block an hour for my CDO talk at the EclipseCon!
Published by Eike Stepper

7 comments:

  1. Bernd KolbMarch 11, 2009 at 11:16 AM

    Very very cool!!!

    ReplyDelete
  2. PascalMarch 11, 2009 at 12:35 PM

    >compensate p2 issues with missing, non-EPL dependencies
    This is misleading. p2 has no issues whatsoever with non-EPL dependencies. The foundation has problems with hosting those: https://bugs.eclipse.org/bugs/show_bug.cgi?id=246945

    ReplyDelete
  3. Eike StepperMarch 11, 2009 at 12:43 PM

    Le ScaL, You're partly right. But I still consider it a p2 issue that the "optional" flag for included features is not respected by p2. Instead p2 just refuses to install the containing feature. And I also consider it a p2 issue that the user is not given the chance to opt out of the strong consistency policy. There are cases where missing dependencies of only some bundles do not necessarily lead to malfunction of a bigger feature.

    ReplyDelete
  4. Eike StepperMarch 11, 2009 at 12:46 PM

    Nearby, I posted a respective question to the Equinox newsgroup almost one year ago ("[p2] Invalid configurations?") -- and never got an answer.

    ReplyDelete
  5. Eike StepperMarch 11, 2009 at 12:53 PM

    Not to mention Bug 250015 which is waiting for reaction since August 2008 ;-)

    ReplyDelete
  6. HenrikMarch 11, 2009 at 2:34 PM

    Great work! This looks like a great way forward for CDO. When is this planned to be "stable" and ready for a CDO release?

    ReplyDelete
  7. Eike StepperMarch 11, 2009 at 6:28 PM

    Henke, I expect the branch to be merged to HEAD by end of this week. HibernateStore might follow next week.

    ReplyDelete

Subscribe to: Post Comments (Atom)