I am seeing 16,777,215 bytes of data stored in the media_mover_files.data column. It consists of serialized array of media mover data which contains the node object which contains the media mover data....

This results in fatal memory_limit and max_allowed_packet errors.

Comments

mfb’s picture

Additional info: I am only seeing this issue when I use the Media Mover CCK module to store the files.

arthurf’s picture

I just did a bit of refactoring which I hope will address this- can you update to latest dev and see if that works for you?

mfb’s picture

szczym’s picture

Confirming, i also run into those memory problems with mm+cck but im able to trace it or recreate it.

abw’s picture

arthurf’s picture

@abw - no #915230 covers the 2.x branch, fyi

@mfb - can you give me an overview of what your configuration looks like? I'm wondering if this is a specific MM module or something stupid I did with where the node data gets merged (likely both)

postplanck’s picture

This bug has really serious consequences in my case, my media_mover_files table has 130 MB for just a few media mover files!!! (Remark: Apart from that terrible recursive effect, why in the first place do you store an extra copy of the node object to the media_mover_files.data column? Serialized node objects can become quite large, in my case e.g. because the calais module is terribly verbose. Isn't the whole point of the drupal hook API that node objects should _not_ be stored by whoever feels inclined to do so, but rather be assembled by calling the various hooks? Never store data twice!)

The recursive effect is created because the mm_cck.module attaches the full node object to the $file['data'] object (in function mm_cck_node_save(), line 498: $file['data']['node'] = $node;), which is serialized and saved to the DB by media_mover_api_file_db_add() or media_mover_api_update_file(). However, the node object at that point already may contain a property "media_mover" (created in media_mover_api_nodeapi() on node load), which in turn contains all the $file objects representing the media_mover_files associated with that node. These $file objects contain the 'data' field, which in turn contains the node object, which contains a media_mover property, and so on. So, on every update of a node containing MM files, one new iteration of the loop is performed, exponentially augmenting the amount of data stored (and loaded on every node_load(), even if no media_mover operation is performed).

A quick solution would be to abort the loop by excluding the "media_mover" property from the $node object that is written to the 'data' field. However, even if not stored recursively, node objects can become very large and therefore shouldn't be written to the 'data' field. Why don't you just load the node using the nid?

arthurf’s picture

Are you experiencing this bug with the latest dev version?