Whoops - I did not associate the comment with the "@example" - Mainly because this annotation is new to me, and there is a line break between the annotation and the example itself.
Thats cool - but these functions are spread all over the classes. Adding the access scope modifiers would be nice .
I got two more things to add to my list that i wrote in the comment section earlier:
Named Scopes
Are these supposed to work? I cannot use the standard approach to define a named scape.
e.g.
public function type($myType)
{
$crit = new EMongoCriteria(array('condition' => array('attr' => $myType)));
$this->getDbCriteria()->mergeWith($crit); <-- FAILS. $this->getDbCriteria() is an array, not an object!
return $this;
}
Also if I try it the other way around - $crit->mergeWith($this->getDbCriteria()) - it is not working because the dbCriteria is possibly just NULL.
EMongoDocument::getPrimaryKey()
I know that the primary key - at this stage - is not supposed to change. But if you could add a method to return the value of the primary key (just like CActiveRecord::primaryKey) i could use this in my code to ensure that i get the correct value.
I don’t know if this makes sense because at this stage of the extension it would return just the “_id” property as hardcoded value. Since I am not that much into MongoDB I also don’t know if it is common to change the name of the PK to something else.
In models using this extension this function should only exist in one place, in the EMongoDocument.
I wish I had taken out the criteria class now.
It doesn’t work with the merging in scopes, they are completely array based.
If I am honest I only added the EMongoCriteria class in case there was something I was missing about it.
Hmm yea I have changed the way to define scopes, I should add that to the documentation with an example. Basically I have taken out the criteria object from it entirely.
I mean that many functions within your extension lacks of the (private/protected/public) access scope modifier
EMongoModel::__construct()
EMongoModel::attributeNames()
EMongoClient::init()
EMongoClient::connect()
Almost the whole EMongoCursor class
to name a few.
Thanks a lot for your insane fast responses and implementations. Named scopes helps me a lot . Too bad that the aggregation framework is not supported somehow. But I understand that it isn’t fitting well into AR .
Hmm I could always add a aggregation helper to the model so that you don’t have to use the mongodb object directly, that should at least make the collection names more modular within the app and also hopefully that should be all accessors plugged in now
Thanks for the awesome testing you have been doing, it has really helped
If a shortcut like MyCollection::model()->aggregate() instead of Yii::app()->mongodb->MyCollection->aggregate() makes sense, I would be glad to have this implemented. Otherwise I am totaly fine with the extension at this point .
Just tested the named scopes and I found a Bug there.
Lets say I’ve Collection::model()->scope()->find(); the scope applies some conditions to the criteria.
Now if I call Collection::model()->getDbCriteria() I expect to have a totaly new model and therefore an empty criteria. But to my suprise the criteria from the scope is still present in the criteria of the new model!
BTW: Could you add an alias for findBy_id and name it findByPk - So it can be used the Yii way .
Indeed I did notice that about scopes. Originally I thought it was a bug but I apply scopes like Yii does so I eventually just said that maybe it is a Yii thing (those parts are actually a straight copy from CActiveRecord). I will take a new look into that now that I kow it ain’t.
I checked CActiveRecored again and it turns out that when Yii queries and it calls "applyScopes" it also resets them in that function so that the cached static instance of the model is never effected by finds() etc.
Using EMongoDataProvider with CListView reveals an other small bug. Yii expects the data returned from CDataProvider::fetchData() to be index based. Currently its an associative array where the key is representing the PK of the document.
The fix is very simple: In EMongoDataProvider:108 change this line
Surely there must be a way to put both a composer compatible autoloader in the source tree, so that this can be put on packagist? I’m not sure I see how there would be a conflict with that one and the regular Yii autoloader, the latter which would simply be loading classes as usual and the composer one wouldn’t be used in this case. Thoughts?
Great, thanks I think it’s super easy, just have a look at https://github.com/Crisu83/yii-less or some other one of Crisu’s extensions to see an example.
I’ve recently started using Composer and it’s a real breeze to just add a line in your ‘require’ array and run composer update and have it all managed for you. Also easy to set up namespaces and autoloading.
Indeed that is very simple, I don’t even need to use the composer autoloader if I just have to provide configuration like that.
I’ll look into completing this today.
I have written a composer.json file now which should work but whenever I attempt to upload it to the packagist site it keeps saying they had a problem their end, I try to clean my browser session and re-log in but then I get a 500 error :\.
Is there an easy way to display validation errors of embedded documents and embedded arrays through CHtml::errorSummary($model) or CHtml::error($model)? How do you realize validation process in your applications?
It uses much the same setup as Yii but nested within the root document in array form. Hmmm, it seems that the error summary cannot just take a plain array which kinda sucks.
I might need to write an additional little function some where that can do what CHtml cannot.
.
.
.