Doctrine 2 Object Relational Mapper (ORM)
0677423d14
> instead of loading the whole result into memory at once is not the full truth. There is a certain risk of processes getting killed due to memory allocation with large iteration. This is caused by result buffering of the client not being visible to PHP and thus not from 'within' the process. It is not certain that this occurs with all database clients but seems rather likely to at this point. This is only a proposal for discussion as I am not certain how to best add the information or if to add it at all (was it obvious before?). Personally I got confused by the existing description and didn't notice the memory implication until further investigation using `top` reported the process to run at 3+GB memory while PHP reported 400M real peak usage. |
||
|---|---|---|
| bin | ||
| docs | ||
| lib | ||
| tests | ||
| tools/sandbox | ||
| .coveralls.yml | ||
| .gitattributes | ||
| .gitignore | ||
| .gitmodules | ||
| .travis.yml | ||
| build.properties | ||
| build.properties.dev | ||
| build.xml | ||
| composer.json | ||
| CONTRIBUTING.md | ||
| doctrine-mapping.xsd | ||
| LICENSE | ||
| phpunit.xml.dist | ||
| README.markdown | ||
| run-all.sh | ||
| UPGRADE.md | ||
Doctrine 2 ORM
Master: 
2.4: 
2.3: 
2.2: 
2.1: 
Master: 
Doctrine 2 is an object-relational mapper (ORM) for PHP 5.3.2+ that provides transparent persistence for PHP objects. It sits on top of a powerful database abstraction layer (DBAL). One of its key features is the option to write database queries in a proprietary object oriented SQL dialect called Doctrine Query Language (DQL), inspired by Hibernates HQL. This provides developers with a powerful alternative to SQL that maintains flexibility without requiring unnecessary code duplication.