Variable objects should have a sensible __repr__

Bug #194031 reported by Kevin McDermott on 2008-02-21
2
Affects Status Importance Assigned to Milestone
Storm
Low
Unassigned

Bug Description

From the logs for Landscape...

TimeoutError: 'SELECT memory_info.computer_id, memory_info.free_memory,
 memory_info.free_swap, memory_info.id, memory_info."timestamp" FROM
 memory_info WHERE memory_info.computer_id = %s AND
 memory_info."timestamp" >= %s AND memory_info."timestamp" <= %s ORDER BY
 memory_info."timestamp"', [<storm.variables.IntVariable object at
 0x2ac733ad3690>, <storm.variables.DateTimeVariable object at
 0x2aaaad072450>, <storm.variables.DateTimeVariable object at
 0x2ac733ad33d0>]

It would have been more useful to know that the IntVariable and DateTimeVariables were.

James Henstridge (jamesh) wrote :

The main problem I see with your branch as it stands is the use of Variable.get().

If the variable is set to a lazy value your repr() implementations will emit resolve-lazy-value, which will run an SQL query to resolve the value and modify the variable's internal state. As the repr() method is mainly used in debugging, it would be good to avoid this.

Changed in storm:
importance: Undecided → Low
status: New → Confirmed
Robert Collins (lifeless) wrote :

Would love to see this fixed, FWIW.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers