Comment 1 for bug 744771

Responding to Prageeth's comment on bug #744035:

> 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.

OK. But I still see a problem: the base class is going to need to have the wrapped type. For example, if the Data class has a Blob, then there will need to be a corresponding Object (deserialised) in the wrapped type. Therefore, the Data class will have a field for BOTH the deserialised Object AND the Blob. True, the deserialised Object could be null in the Data class, but then we're talking about a type A with a field that is never null, and a subclass B where the same field is always null -- technically B violates the constraint of A , because you cannot use B in place of A.

At this point we are into a very bad design: we are using subclasses ONLY to avoid code duplication and not for any other practical benefit which means they are being misused.

Couple that with the two-tables problem ... I still think we should just avoid this and go with a simpler model.

Rather than replacing this with two separate classes, I think it would be best if we just provide an API to read each individual field (after all, we have APIs for setting individual fields, why not getting as well?)

> 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).

I don't like this approach. The database should be treated a bit like the user interface -- it should not expose nasty things in the code. Much like a user interface, you should be able to refactor the code without having to change the underlying data representation. It isn't cool if our data store has a bunch of tables just there because of a way we wrote the code.