fODM, fODMDatabase, fDocument, fCollection

[wbond]

Ticket #568 by @mattsah:

This is a ticket to discuss and work on the possibility of adding document database support to Flourish. I have dome some initial implementation on my personal fork, however, it would be nice to see some support get mainlined into the trunk. With that said, here's a few things out of initial discussion with Will as well as additional research.

Aimed support:

• MongoDB
• CouchDB

MongoDB is much better suited for the proposed structure than CouchDB, namely because it has a built in concept of Collections as well as being the only document database (not simply key value store) with official PHP support it seems. Additionally there are aspects to the API that map well to the existing fDatabase API, although albeit, without SQL.

It seems as though there are two approaches which could make this work cleanly, although one would likely add significantly more code and repeat similar logic found in fORM, fActiveRecord, etc.

1. It is possible to create a completely alternative Document driven Object Mapper independent of the common ORM/Relational base with classes such as those listed above.

2. It is possible to centralize and abstract similar code into additional base classes, and then simply have fODM and fORM, for example, using the common base class for common logic. Similarly, fDatabase would SQL related tasks moved to fRelationalDatabase or fRDatabase while the specific but similar fDatabase API would use fDocumentDatabase or fDDatabase.

Benefits of the first approach is that there will be no need to independently check whether we are dealing with ORM or ODM in the base classes. This means someone could completely and independently implement fODM from any fORM related code. Major downsides is that a number of classes would have to be re-implemented. While Document Databases tend not to have a defined schema or SQL support, using a number of similar methods to what is allowed in normal fORM operations, one could easily create a number of validation and enforcement rules for schema-less databases, while the existing fORM code works with the schema validation as well as additional validation or ORM rules applied on top. This would mean on adding relevant classes for EVERY similar aspect: fODMNumber, fODMFile, fODMValidation, etc. I count about 13 new classes at least given the current size of the ORM count.

The benefit of the second approach would be that we could concentrate similar functionality and api in more core classes — for example fMapper, fMapperNumber, fMapperFile, fMapperValidation — or something similar. From here only the specific differences could be added into fORM and fODM prefixed classes. One major downside of this, of course, is huge breaks in backwards compatibility.

A mixed approach could add base classes + all related prefixed classes which would simply wrap the base packages in the initial API. Keeping the core API semantic would be ideal, so for example fORMtablize could be abstracted into fMapperclassToPool, from which fORMtablize and fODMcollectionize would simply call that.

This would allow for consistent but semantic naming along with limited backwards compatibility breaks. Many fORM vs. fODM method names would be similar and follow similar API but would reflect the differences between core terminology, meaning if you know one you could work with the other very easily, but it would also remain intuitive to each class set.

On the issue of the databases themselves, part of the problem remains their disparate API as well as lacking support in PHP. For example, while MongoDB has a built in concept of collections, CouchDB does not, and it is up to the author to group documents via a property. This being said, one approach might be to make fDocument non-abstract, so that a Document is a Document is a Document, if when instantiated the class of $this is not fDocument, additional steps could be taken to work within the approriate collection for MongoDB or similar databases, while in the case of CouchDB a property could be added to the document automatically to specify its collection.

CouchDB, does, however, provide the concept of views, which could for example be established as such:

function(doc) {
    if (doc.Collection == "collection_name") {
        emit(null, doc)
    }
}

However, from what I can tell there is no way to determine which views would be related to simple collections vs. which represent more complex map functions. In this sense, despite not having a schema, CouchDB is even less "schema-less" than MongoDB, as with MongoDB it is possible to list/show collections at least similar to getting a list of tables.

These are some initial ideas on the subject, and I will likely continuing developing some of them on my own fork to see what seems to work and what doesn't with more updates to come.