On Nov 16, 3:38 pm, "Michael Bayer" <mike...@zzzcomputing.com> wrote:
> id like to know what errors specifically you get which aren't fairly
> obvious even if they happen later on. I'm guessing some of the
> "dependency" oriented messages like "dependency rule tried to blank out
> primary key".
Nah, the particular one I stubbed my toe on today was:
TypeError: can't compare offset-naive and offset-aware datetimes
... caused by accidentally slipping a non-timezone-aware datetime into
a query/operation somewhere (with timezone-aware datetime columns, on
PostgreSQL).
But I have also found myself wanting this when debugging general
ProgrammingErrors --- I get all kinds, because I am mixing ORM and
sqlexpression calls with literal SQL through session.execute() ---
unavoidable because my model is fairly dynamic (a sort of generalized
warehousing application, thousands of tables, bunch of bulk operations
and DDL at runtime).
> It's always an easy option to add more contextual
> information to our exception messages if that helps.
The exception messages are generally fine --- rather, I'm after more
accurate contextual exception stack traces (not generally, just when I
particularly ask for it).
> This is the 2nd use case in a couple of
> weeks where such a "proxy" system is useful, leading to the notion of
> having a common extension that allows generic "wrapping" of attribute
> operations ...but like that other use case, both are cases that I'm not
> entirely convinced are even necessary.
My case is absolutely not necessary. Just an idea for debugging
convenience.
> well as far as performance, that would be entirely out the window. and
> yeah constraints like composite primary keys and such wouldn't work. But
> also, this level of meddling is definitely not something I'd want to see
> in the core, adding conditionals to everything. Implementation wise it
> would be a SessionExtension that intercepts "attach", plus the
> abovementioned proxies for InstrumentedAttribute and CollectionAdapter.
Yeah, performance would be abysmal, but one would only do this when
debugging anyway.
Thanks for the pointers --- I'll give the SessionExtension (&Co.)
approach a try, if I get another troubleshooting case that itches
enough. If I come up with something useful, I'll post it here or put
it on UsageRecipes.
- Gulli
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---
