This may be unrelated, but I have a very similar issue in Turbogears 1.x (all really old versions of TG and SQLAlchemy). Every few days the mapper loses the mapping, i.e. there is a table that either suddenly "misses" a column, or more frequently, the data type goes missing and I get errors like that I can't sum up to int columns, where the second columns suddenly turned into something not an int (the error doesn't tell what data type is assumed at that point).
Restart solves the problem. Me thinketh that SQLA is the issue here. I never dug into the problem since it mostly runs. I opted to wait until I get around to porting my app to 2.x. Meanwhile I wrote a script that parses errors in the log and resets the server when these kind of errors happen. On a side note, if anyone with more indepth knowledge reads this: the error when it occurs always hits all instances. I run TG1.x in 3 processes with a proxy in front (no wsgi, that old version of TG didn't like it). For some reason the database connections seem to be shared between the 3 processes. Therefor I can't reset one process at a time, I have to reset all 3 of them simultaneously (aka killall python ...). So it may have to do with SQLA and psycopg, as the 3 processes sharing db connections seems a bit odd unless the problem occurs closer to the database (postgresql in this case). BTW: I auto- reflect all tables (I hate ORMs and never could figure out why I should rewrite the db model in python when I already wrote it in the database. IMHO ORMs are only really handy for object mapping, but the whole querying and particularly re-writing the model is just tedious. Well, my $0.02 - I'm old school and like my database straight up, no salt, no ice and no water - hehehe) Well, maybe some fodder for thought. James's problem sounds very much alike, so I thought I share my observations. Uwe On Fri, 08/09/2013 07:53:44 AM James Carroll wrote: Hi, I've done lots of turbogears in the past, and never had the problems that I'm having with pyramid + Sqlalchemy. I'm getting errors that I've never seen before, and then the session holds on to them and brings every service down until I restart. One clue is that sometimes we get nonsense errors when we do many requests back-to back, like NoSuchColumnError: "Could not locate column in row for column 'store.id'" And of course the store has an id column... Sometimes it shows up as: NoSuchColumnError: "Could not locate column in row for column 'count(*)'" This is happening when the requests are made against just a simple pserve my.ini. I'm using a simple: DBSession = scoped_session(sessionmaker(extension=ZopeTransactionExtension())) in my models.py -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/pylons-discuss. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/pylons-discuss. For more options, visit https://groups.google.com/groups/opt_out.
