Comment 2 for bug 744035

OK now I remember why I came up with the concept of having two classes for each model class.
In cases as mentioned above, I have a way around IF we continue to have the current concept.

What I would do is, basically have two extra retrieve and update (basically get and set object itself) methods in the ModelDataClass interface. This way, the ModelClass (exposed to the client) can actually have the Object type value. However, the ModelDataClass implementation of KeyValuePair (KeyValuepairData) would have an extra field which is the blob.

So all you do is, override the two methods mentioned above that handles the translation from Object to Blob and vice versa. And, in other model classes, we can simply return the same value without doing any operations?

This hides the blob from the client and the client classes can have any fields we want; but the data classes will have JDO persistence fields.

I can do this tonight, but Matt would have to wait till I finish implementing this; I'll take about 30mins to completely implement it and get it working that way.

But this still brings rise to the issue of having two tables per model class. I personally think this adds more features to the model and we can live with having 10 empty tables that are never used (not much of a space or performance issue).