This is my legacy ...

Wednesday 31 March 2010 at 8:05 pm ...mode. Or more precisely it's CDO's. Finally, as Eike announced on EclipseCon, we managed to finished this new feature.
"Cool" is what comes into your mind while reading this lines? And while you have back in mind that CDO recently released the offline mode, euphoria let's you shiver anticipation about another fancy feature in CDO? But then a wreckful question destroys all your happiness and you ask yourself: "What is legacy in the context of CDO?"
Well, if so, let me get you out of this mess and explain what the legacy mode is about.

If you remember CDO's getting started you probably had noticed that you had to convert your model to CDO. This step adapts your genmodel and changes some generation relevant settings. The most important of these changes is that instead of directly inheriting from EObject your model classes will extend CDOObject, or to be more accurate - CDOObjectImpl. This conversion results into the flexibility and scalability CDO offers. If you like to know more about the internals read the CDO wiki page. Just to sum it up - after the conversion your model is CDO-ified, or in other words: CDO Native.

Well, although this conversion gives you full access to CDO, like lazy loading and unloading, some don't like to or just can't convert their models. To be honest, when I started developing Dawn I also found this conversion tedious, not understanding the real meaning of it. But in my defence - at this time I did not even know what EMF is about ;) And because this was also the time Eike still proclaimed that there is no need for an offline mode in CDO I think we both are even now. ;)

But back to the topic. What if you can't use a native CDO model? For example if you only have the generated binaries. Then the legacy mode comes to your support. When legacy support is activated it is now possible to use pure EMF objects (legacy objects in the context of CDO) with the CDO repository. This makes it now easy to share your model even if it is not converted. But keep in mind that the legacy approach leaves you with the given disadvantages concerning scalability. So if you need the maximum of scalability and performance on huge models, you should use the native mode. But for smaller models legacy performs well. It is even possible to store the objects in legacy, than convert your model and proceed with a more scalable und flexible resource.

Legacy is not only limited to generated classes. In fact you can use it with DynamicEObjects if you want to. Again, it is recommended to use native objects. And in the dynamic cases it makes even more sense be converting the model is done easily using CDOUtil.prepareDynamicEPackage(dynamicMapEPackage), because you do not need to regenerated your classes. But if you want to use DynamicEObjects on CDO, for what reason ever, you are free to do so.

That's it? Not by a long shot. With the legacy mode, if required, legacy and native objects can be used combined. If your native model needs to reference a model which cannot be converted or vice versa this is now possible with CDO.

You might wonder how legacy performs compared to the native approach. The Legacy Mode is slower, in most cases, because it is just a bridge between pure EMF and CDO. But the loss of performance is not that big and only applies to the client side. Legacy mode is completely transparent to the server. This makes it possible to convert legacy to native and vice versa as mentioned above. Have a look at the picture below. The graph shows some simple performance measurements between native and legacy. You can see that the difference between native and legacy it not that big.

One question remains. How to use this new fancy feature? In an early design legacy was adapted automatically to CDO. But this has a major drawback. People could forget converting there models to CDO. This fact alone would not be that troublesome. But imagine now that this user runs into an error with a stack trace which does not point directly to legacy, even if it was the root of the problem. In this case it could be hard work to hunt it down. That's why we made legacy support configurable. And by default it is turned off. This leaves legacy to the once who are aware of it.
To switch legacy support on or off you can refer to static methods in CDOUtil. This will influence the setting for newly created CDOViews. Note, that these methods are only setting the default behaviour for the current thread. So you must ensure that you set the flag for the right thread.

boolean CDOUtil.isLegacyModeDefault()  void CDOUtil.setLegacyModeDefault(boolean on)

The snippet below shows how legacy can be enabled or disabled.

CDOSession session = ...; CDOTransaction transaction1 = session.openTransaction(); //this transaction is opened with no legacy support which is the default CDOUtil.setLegacyModeDefault(true); CDOTransaction transaction2 = session.openTransaction(); //this transaction is opened with legacy support CDOUtil.setLegacyModeDefault(false); CDOTransaction transaction3 = session.openTransaction(); //this transaction is opened with no legacy support again

Additionally you can ask your view whether legacy is enabled for it by using the following method.

CDOView view = ...; boolean isLegacy = view.isLegacyModeEnabled();

Last but not least I would like to thank our sponsor who made it possible to spend a major effort on the development of the legacy mode.

Now, feel free to test it and give us a feedback if you like ;)

EMF rocks!

Tuesday 23 March 2010 at 1:37 pm Well, this is a statement the most of you are certainly aware of. But there might be some out there who have not already been assimilated or who have never ever heard of model driven software development at all. For those and certainly for all others I'll give some thought about one of my latest EMF experiences.

But let me start at the beginning. I believe that it is quite a good idea to have a playground, an abstract idea or project, where you can try out new technologies. If you implement this idea with different technologies this gives you a good overview about the advantages and drawbacks of the different approaches. Well, my playground is called the "Moviebase". Long, long time ago when I made my apprenticeship I learned a bit about web servers, PHP and databases and so I came up with the idea to develop a small application to manage my movies.
O.k. the desing was not perfect but actually stable enough to work for several years. Later in university I learned a lot about fancy new technologies like servlet containers, web services, AJAX, RSS, Hibernate (at this time they were new) and all the other interesting technologies which let the buzzword catalogue grow bigger and bigger. So I decided to re-implement the Moviebase using the new stuff.

Well, this is also some years ago, but I remember having some trouble with the following scenario:
A movie has actors. So far so good. That's actually true for most movies - except documentations. But to be honest, documentations are not the majority in my movie catalogue. Because I haven't heard about modelling or EMF at all I started coding this specific classes and lists for it by hand. I quick typing action and I was able to get all actors from the movie. But movies have directors, too. O.k. this brought up the base class Person and it's subclasses Actor and Director. Added getter and setter and it was done. Hmmm, who wrote the sound track could be interesting, too (especially if you intent to write a MusicBase and combine it with the MovieBase). So again some typing actions brought the needed code.

That's enough for the model. And now it is time were the trouble starts. Getting/setting actors and so on is nice. But what if you would like to see all persons involved in a movie? O.k. writing a method called "getPersons" would do the trick - if you take care that the persons are not doubled - some actors are also playing director or compose the music for the movie. And deleting a person is even worst. But that is not the real problem. For now we took to a look at movies. But what about the Person object? Don't you want to know in which movies he played or where she was director? Or maybe you want to retrieve every movie the person was involved? Writing this and taking care for the integrity of all lists could be quite troublesome.

But to cut the long story short, all these problems are easily solved with EMF. To be exact - with FeatureMaps. To be honest I never liked FeatureMaps before I used them. ;)
But you can easily model the above mentioned scenario Just create an attribute with type FeatureMapEntry in your movie called "persons". Then add actors, directors and composers as may-valued references and combine them using the EAnnotations described in the EMF book. Do the same for the persons and let them point the the specific opposite in the movie. E.g. Person.moviesAsActors point to the actors feature in the movie. That's it. Now you have bidirectional FeatureMaps. Just generate the code and EMF will care for the rest. You can add movies to actors or directors to movies and the whole synchronisation will be done by EMF - groovy. Just see the snippet below for an examples


Person person = MediabaseFactory.eINSTANCE.createPerson();
Movie movie = MediabaseFactory.eINSTANCE.createMovie();

movie.getActors().add(person);
movie.getDirectors().add(person);

System.out.println("persons:" + movie.getPersons().size()); //prints 2

System.out.println("actors:" + movie.getActors().size());//prints 1
System.out.println("directors:" + movie.getDirectors().size());//prints 1
System.out.println("composers:" + movie.getComposers().size());//prints 0

System.out.println("MyMovies: " + person.getMovies().size());//prints 2
System.out.println("MyMovies as actor: " + person.getMoviesAsActor().size());//prints 1
System.out.println("MyMovies as director : " + person.getMoviesAsDirector().size());//prints 1
System.out.println("MyMovies as composer: " + person.getMoviesAsComposer().size());//prints 1

And that is not only reliable and stable but can also be modelled quite fast. If you know what to do you can define this model in just a few minutes. Not yet convinced using EMF? Try it out and I guess you will ;)
This was a small insight into the advantages EMF offers. Unfortunately my time is limited at the moment, so the MovieBase development slowed down. But I already had some time to play with EMF Databinding - and hey - it rocks too ;)

So, wherever you are - Have fun and enjoy the springtime. :)