get_cls_info get_obj_info

[Tomasz Kopacki]

I have this strange stacktrace when im calling store.add(object):

Traceback (most recent call last):
  File "/opt/voip/businessLogic/interface/UserInterface.py", line 40, in createUser
    UserLogic().createUser(login, password)
  File "/opt/voip/businessLogic/data/logic/UserLogic.py", line 32, in createUser
    StoreManager().persist(user)
  File "/opt/voip/businessLogic/data/StoreManager.py", line 36, in persist
    self._store.add(object)
  File "/usr/lib/python2.6/site-packages/storm-0.20-py2.6-linux-i686.egg/storm/store.py", line 260, in add
    obj_info = get_obj_info(obj)
  File "/usr/lib/python2.6/site-packages/storm-0.20-py2.6-linux-i686.egg/storm/info.py", line 54, in get_cls_info
    cls.__storm_class_info__ = ClassInfo(cls)
  File "/usr/lib/python2.6/site-packages/storm-0.20-py2.6-linux-i686.egg/storm/info.py", line 73, in __init__
    raise ClassInfoError("%s.__storm_table__ missing" % repr(cls))
ClassInfoError: <type 'instance'>.__storm_table__ missing

what is interesting:
    obj_info = get_obj_info(obj)
  File "/usr/lib/python2.6/site-packages/storm-0.20-py2.6-linux-i686.egg/storm/info.py", line 54, in get_cls_info

if get_obj_info is called, why stacktrace shows an error in get_cls_info ?

[James Henstridge (jamesh)]

Storm uses a C extension to accelerate some frequently used functions/classes in the code. The get_obj_info() function is one example.

C functions do not have stack frames when unwinding an exception, which is why the traceback skips forward to get_cls_info().