4

When dealing with nested ORM relations, using cfdump or writeDump can rapidly result in java.lang.OutOfMemoryError errors because CF attempts to resolve relations in nested objects and dump too many objects.

This can be avoided with the top attribute, for example: <cfdump var=#SomeObject# top=3 />

It's a pain to remember to write this all the time - is there any way to configure CF to not go down too many levels when dealing with ORM objects?

Peter Boughton
  • 110,170
  • 32
  • 120
  • 176

1 Answers1

5

There doesn't appear to be any administrator settings for this. (issue raised)

An imperfect solution is to create a wrapper for the cfdump tag by renaming {cfusion}/wwwroot/WEB-INF/cftags/dump.cfm to (for example) origdump.cfm then creating a new dump.cfm file containing:

<cfif isObject(attributes.var) AND NOT StructKeyExists(attributes,'top')>
    <cfset attributes.top = 3 />
</cfif>

<cforigdump attributecollection=#attributes# />

<cfexit method="exitTag" />

Fortunately, the writeDump function will call this wrapper (so it works for both tag and function).

Unfortunately the wrapper is not called recursively - if the ORM object is in a struct or array then the original problem still manifests itself - it may be possible to pre-scan complex variables to determine if there are relationships inside and set an appropriate top value, but only a limited solution could be achieved with this (i.e. it would affect neighbouring structs/arrays).

Peter Boughton
  • 110,170
  • 32
  • 120
  • 176
  • That was the solution I was about to recommend. I'm not quite seeing the recursion problem when desk-checking this in my head (which I guess is not desk-checking, per se). Recursive calls to `dump.cfm` from within `origdump.cfm` would be passing a `top` attribute to the `dump.cfm` call would it not? So for argument's sake your initial call to `dump.cfm` has no `TOP` param, but it calls `origdump.cfm` with `top=3`. `origdump.cfm` then internally calls `dump.cfm`, passing `top=3`, which your `dump.cfm` wrapper respects, no probs. Or do I need to get the pen and paper out and desk-check properly? – Adam Cameron Aug 05 '13 at 10:24
  • 1
    Sorry, not sure I explained it too well. The wrapper is only called for the top level - i.e. if you do `` then the top condition fails (var is array, not object), and the check is _not_ performed for the array's children. So the top check would need to be updated to look for containers (arrays/structs) then check their child nodes and set top appropriately, except doing that would not work for situations like `{one:object,two:[[[[a,b,c]]]]}` because the full contents of two would fail to display. Make sense? – Peter Boughton Aug 05 '13 at 10:36
  • (Of course, that's only an issue when there are non-object values at a depth of object+3 - not sure how common an occurrence that is in general.) – Peter Boughton Aug 05 '13 at 10:40