I have looked at the source code, briefly, and the problem is that the module is a complex "beast" that relies heavily on the core's API which I am not currently familiar with.
I have a kind of pieced together on how Drupal assembles a completed node object by traversing the various tables (node, node_type, field_config, field_config_instance, etc).
What confuses me is the data abstraction layer. field_config has a storage_type which appears to indicate whether a field is stored in SQL or not.
From what I have read and interpreted, Drupal is flexible enough to have a system which is data store agnostic, so if I had a products content type and capacity out-grew what MySQL was capable of, I could (in theory) switch to MongoDB or similar DBMS which allows better scaling.
So, how would I attach a field to a content type, which let's say was stored in Mongo, but the remaining fields stayed in SQL?
More interesting, how does VIEWS deal with this disconnection in data storage? If I store some fields for a given type in MongoDB and some in SQL how does VIEWS handle the JOINS and filtering capability?