ObjectSpaces: The Matrix is not Enough

In response to my earlier post, “Spanning the Matrix“, Ralfs Sudelbücher has something to say about building O-R mapping engines in “Spans in ObjectSpaces are not Enough.“ 

He is making the point that it is not enough just to describe which associated objects/collections should be retrieved along with the primary objects of the query, that you should in addition be able to specify exactly which properties of an object are retrieved to avoid pulling back too much data.

I have to agree that it would be desirable to do this for may particular scenarios, however, as long as the objects and schema remain static throughout your applications this has a variety of drawbacks.

1) Selectively populating data for an object has a big downside if you ever intend to pass off this information to another part of your application or someone else's component.  The object itself does not encapsulate the semantics you were implying by restricting certain fields of information, so another piece of code that sees instances of the same object may very well assume all data is accurate.  Even if the properties are encoded using something equivalent to NULL, it is not evident given an object is the data is really NULL in the database, or it was just omitted from the query.

2) Behaviors built into the object may depend on data being available.  For example, a read-only property that calculates its value based on other fields would be impossible if you could merely omit certain fields given a query. 

The only rational thing to do would not be to omit properties during a query but to project your data into a new strongly typed object definition that would correctly describe the result set that you want.  You would basically be re-encapsulating your data and would likely not have any behaviors associated with the result at all. 

You really have to decide whether you want objects to be bastions of behavior, that describe fixed semantics over your entire database schema, possibly encoding strong relationships between properties as well as stronger criteria such as cardinality.  This puts you in a world where your objects are truly just mirrors of the database state in the truest Object-Persistence world view.  Or you have to decide that your object-data is really just a projection of this meta model, and that the results you obtain in your application code are merely just the resulting data, and there is no strong tie back to the semantics of the database.  You can only have consistency given these two extremes.  There is no middle ground.

So are your objects data or are you data objects?

You decide.

Matt