On Feb 10, 2006, at 4:07 PM, Alan Franzoni wrote:
while I've just begun using SQLAlchemy, I already love it ^_^.
glad to hear it !
It's just missing one feature I'd really see in it, since it's an
evergreen: consistent error handling. I can't find a tracker for
this piece
of software, so I don't know if it's already in the want list for 1.0.
tracker is right via trac: http://www.sqlalchemy.org/trac/newticket
log in as guest/guest
TypeMismatchError - type mismatch
NotNullError - if trying to insert None in a NOT NULL column
ForeignKeyError - if trying to insert a non-existent FK ID
IntegrityError - trying to remove a referenced row
UniqueError - if violating an Unique constraint.
CheckError - generic check violation
ConstraintError - generic constraint violation
assuming you are talking about anticipating errors before they
happen, it seems like this might be some kind of constraint-checker
that takes in database metadata and validates potential input
statements against it. that might be a useful product but I would
consider that to be a separate piece of software...it amounts to
writing about half of an RDBMS in Python...maybe one of the existing
pure-python databases could provide a starting point. SQLAlchemy is
getting "Index" objects in the schema soon, so maybe such a product
can build upon it...but this is way out of the scope of SA itself
(for example....should it scan a table for the existence of
corresponding foreign keys before inserting a new row ? thats a lot
of processing to do, especially in an external process - and its what
the DB is meant to be doing).
if you are just looking for a "lookup table" that matches DB errors
to a common repository of strings, that wont get you very far re:
user validation since the context and content of error messages
varies widely, only a fraction of error messages would even have a
common home; in the case of mysql and sqlite which have little or no
constraint checking, you wont get an error message, just a corrupted
database. User-input should be validated way before it gets near a
persistence layer.
We should also think something about the accessible data of the
exception
instance, i.e. it should contain useful info to tell the user
what's going
on and help him track down the problem.
I can only do as well as the DBAPI lets me know ! passing the
exception straight out is the best i can do with that. It might be
nice to have them "wrapped" in a common exception class but I find
that Python stack traces behave a lot nicer when they are left
untouched.
- mike
-------------------------------------------------------
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
