each has many relations.to generate reports, i need to get most of the data from many table, getting
Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 65488 bytes) in D:\xampp\htdocs\size.dev\fuel\packages\orm\classes\model.php on line 2086
Nothing much you can do about it I think. I assume you are pulling in a lot of records, each row may create a lot of objects.
For example, if you have a parent with 10 children, each having 10 childeren as well, you're creating 111 ( 1 + 10 + 10x10 ) objects.
It is probably a lot more memory efficient you code DB calls for reports, or use get_query() instead of get() to get the SQL generated by the ORM, and then use a DB::query() to execute it.
Yes, Fuel has batch processing available through Oil tasks, but they are restrictedd to the same memory limit.
Exactly, What is the difference between using get() and DB::query().
Any memory advantages? Is response is same?
i fixed it by another method.. http://bin.fuelphp.com/snippet/view/MG now i got no memory truble. but having 24 query.. all are becasue of eav i think so.
Also.....
i have some kind of EAV available. But when ever i call $model->eav_custom_field , i think a new query is executed. I cause memory trubles as so many eav queries are there, can i attach/join the eav meta table parent table? so that further query to every eav request can be avoided.
also.
can you provide me a solution that i can free up memory of orm object after its use on the fly in a foreach loop. i have much truble at reports.
DB::query() returns raw row responses, either in an array or in an object.
ORM get() does the same, but then hydrates the result by spliting the row into the different objects the row contains, creating relations between the objects, etc.
In case of EAV, it's a standard related table. It means that you either include it (by using the related() method) in your query to load it all up from, or the rows get lazy-loaded when you access the property, which indeed will fire a query per EAV attribute.
And you can't, that is the downside of using the ORM. It holds an object cache, and because of all relations you can't simply delete objects without creating side effects.
Hence the statement that you should not use ORM for reports and batch operations, it has way to much overhead.
Donate
