ok...would we want to have all the information_schema tables
available in the ischema module ? if so, would we want to hardcode
them all in, or have most of them pull in through table reflection ?
your use case also raises interesting points:
- for textual bind parameters, I thought you could say:
text('create schema :schema', engine = e).execute(schema='myschema')
but you cant ! hence ticket #35.
- "backend-independent exception". I am usually very big on these
but I left most exception classes out of SA totally to start with,
since I didnt have a clear idea how i wanted to do that - everything
was just "raise <string>". Lately, I have converted a lot of those
related to things passed into the construction of objects into
ValueError()'s.
so the questions with SA exceptions, which I dont have much of an
idea on, are:
- do we use only SA-specific exceptions everywhere, i.e. even the
ValueErrors i am throwing now become SAValueError or something like
that (and would they all extend from a common base exception) ?
- would we want to have a different class of SA exception for every
condition ? or just one or two "catchalls" ?
- would the SA exception maintain a reference to the "originating"
exception ?
- does rethrowing exceptions like that make stack traces harder to
deal with (ive had to do tricks with extract_tb() + extract_stack()
sometimes to re-create a full stack trace) ?
On Jan 13, 2006, at 6:54 PM, [EMAIL PROTECTED] wrote:
<sautil.py>
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Sqlalchemy-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
