Fix the issues #65 and #78 by adding FETCH_OBJ like support

[crazycodr]

#65
#78

[crazycodr]

If you agree on this, i'll just close this PR and start over and do:

Proxy MongoDocument

1. Create proxy MongoDocument class that accepts an array in reference to serve it's content
2. All content served by this MongoDocument will return another MongoDocument if the property is an array with only non numeric keys
3. Support for accessors all go through the magic methods __get, __set, __isset and __unset
4. All MongoDocuments refer to references of data stored in the Model, thus all writes, reads, sets, unsets are done on the original data, keeping referential integrity and possibility to detect dirty attributes by comparing "original" and "data"
5. A MongoDocumentFactoryInterface and MongoDocumentInterface will be create to support multiple versions of MongoDocuments, i foresee this as a good start for custom MongoDocument structures
6. There will be no caching in the MongoDocument, it will always be a clean instanciation because we want to keep referential integrity of data, else, we could end up with two instances of the same data reference but end up with one that cached the existence of a property and the other that deleted it afterwards. This caching could be implemented using a different factory and mongodocument

MongoDocument support in model

1. Install the MongoDocument support in the MongoModel

ServiceProvider binding support

1. Because we will be using interfaces and IoC bindings, i'll modify the service provider to setup default bindings of classes MongoDocument to MongoDocumentInterface and MongoDocumentFactory to MongoDocumentFactoryInterface

I'm waiting for your approval

[ghost]

Having just read over this, the main concern is the move away from Eloquent standards that were clearly laid out in the original brief of this package. That aside, Mongo does not fit the Eloquent standard very well. As @crazycodr says we loose a lot of the power of MongoDB without having specific ways to use it specifically when accessing and setting data without replacing an entire array structure with a new updated one.

I think that the suggestions are certainly viable, and would be a welcome addition to the package. I particularly like the idea of a MongoDocument and would like to work with you chaps on building this.

[jenssegers]

@crazycodr, the proxy object would be a performant implementation, but it would only be possible when working with results returned from the model and not with regular queries from DB.

[crazycodr]

@dyeh The main standards are immediately compromised as soon as you move from a relational datastore to a document data store, there is no way to keep the two in sync unless you don't take advantage from any of the two. Imagine not using joins in SQL but still using only a 2D array to store data in MongoDB.

In all my carreer, i've never seen a project change so drastically as to rewrite the complete data layer because of such major changes. At that point, you need a major release and will also do core replacements.

[crazycodr]

@jenssegers Agreed, but at this point you are not using laravel naturally, you're doing your own query, and the reason for this module is not just a link between laravel and mongodb it's the querying aspect and automatic modelisation, which becomes even more true when we're talking about document databases that map tightly to an object model.

Second, nothing prevents the user from using another special kind of MongoDocument that takes in not a reference but a real dataset and passes on references to sub documents. We'll see what we can do about that later. First things first.

I'll immediately close this PR and revert the changes and start implementing this new revision!

[crazycodr]

I think i messed something up, i'm still not used with forking, i guess i should not have deleted the branch...

I hope it won't mix up stuff when i submit again!

[jenssegers]

The main reason I made this library is for Laravel users to be able to quickly switch between a mysql database to a mongo database without having to change their models or logic. I want to try to stick to the Laravel behavior as much as possible. If users really need to use mongo specific operations, it is better to switch to the native client or to use raw expressions.

Nevertheless, this would be a useful feature that makes the model objects more intuitive. As long as it does not drift away from basic Laravel behavior.