Skip to content
This repository has been archived by the owner on Nov 21, 2019. It is now read-only.

EMongoDocument's EMongoCriteria change when assigning consecutive criteria #51

Open
frvge opened this issue Aug 30, 2011 · 1 comment
Open

Comments

@frvge
Copy link

frvge commented Aug 30, 2011

I was assigning 2 slightly different criteria to 2 EMongoDocumentDataProviders but for some reason, the criteria of the second overwrote the criteria of the first. Because the getData of the DataProvider is run in the view (in a list widget). the results of the second criteria were shown instead of the first. This does not happen if the data is cached via getData before the second criteria is assigned to a dataprovider's constructor.

In the constructor of EMongoDocumentDataProvider:
$this->_criteria = $this->model->getDbCriteria();

If I change this to
$this->_criteria = new EMongoCriteria();

it works as it should.

How to replicate (change the conditions to fit your own model):
$a = new EMongoCriteria('conditions' => array('category' => 1);
$aProvider = new EMongoDocumentDataProvider('MyModel', array('criteria' => $a));
var_dump($aProvider->getCriteria());

$b = new EMongoCriteria('conditions' => array('category' => 2);
$bProvider = new EMongoDocumentDataProvider('MyModel', array('criteria' => $b));
var_dump($aProvider->getCriteria());

First var_dump shows $a criteria, second shows $b criteria, while it should show $a criteria.

@frvge
Copy link
Author

frvge commented Aug 31, 2011

Seems like the constructor and the fetchData of the EMongoDocumentDataProvider is really different from the standard implementation. Is it possible to unify it a bit? That would probably get rid of this problem. I hacked around it, but without proper unit tests and am not certain it'll hold up in all cases.

@frvge frvge closed this as completed Aug 31, 2011
@frvge frvge reopened this Aug 31, 2011
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant