hi mike,
thanks as always for your thoughtful response.
(i hadn't expected a discussion on the little
side-comments in my example!)
On Jan 15, 2006, at 8:37 PM, Michael Bayer wrote:
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 ?
i hadn't considered reflection; that would
certainly make the python-side of things
more terse. on the other hand, that would
also expose the individual quirks of the
underlying db at the engine level - so i
would lean towards not doing reflection.
the counterpoint to this would be, as you
noted before, that since information_schema
is not well supported, perhaps the "practicality
beats purity" approach would be to come up
with a simpler selectable view onto this
kind of db metadata. nevertheless, i think
such a view would end up being mostly a
"lowest common denominator" subset of the
information_schema, so my inclination would
be to just stick with the information_schema
api as the external interface, and do backend-
specific tweaks as necessary.
i'm presuming that the "table_exists" functionality
in ticket #31 would hook into this one way or the
other, and that for common use cases such as this
there would be another "plain function call" layer
on top of whatever selectable interface ends
up being integrated.
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.
thanks for looking into this; i admit that
i didn't look very deeply into doing this.
with regards to the specific expression that
i was trying to execute, are there any plans
to extend sql.py to include direct "CREATE"
statements?
- "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) ?
i don't think so.
i think there are two distinct classes of
exceptions:
1. ones that come from the db backend.
2. ones that aren't.
it would be nice if 1. was useable in
some backend-independent way, (not
necessarily SA-specific, see the dbapi2
comments below) but i don't think 2.
needs to be (or should be) SA-specific.
there certainly may be cases where
the builtin exceptions don't provide
the necessary discrimination between
error cases, but i think that kind of
extension should be done conservatively
on a usecase-by-usecase basis.
- would we want to have a different class of SA exception for every
condition ? or just one or two "catchalls" ?
again, i think not proliferating
exception classes is a good thing -
each new class should be motivated
by a strong usecase.
the dbapi2:
http://www.python.org/peps/pep-0249.html
actually does specify a reasonable set of
exceptions, but unfortunately their use is
not consistent across backends. e.g., if
you CREATE TABLE a table that already exists,
in psycopg2 you get ProgrammingError, while
with pysqlite2 you get OperationalError.
it may be that the "right" thing to do is
to push back patches to the backend projects
in an attempt to make the following of the
dbapi2 exceptions spec more consistent -
then SA wouldn't have to do anything.
- 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) ?
yeah, it would be nice to avoid doing
tricky/hacky stacktrace mangling - so
pushing the backend authors to be more
uniform in the exceptions seems like
the ideal path, although that brings in
a lot more people and therefore politics.
thanks again,
d
-------------------------------------------------------
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://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Sqlalchemy-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
