Michael Bayer wrote: > > 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 > >
I find it convenient to alias any db-specific exceptions I might want to catch, right after I set up the engine: IntegrityError = engine.module.IntegrityError ... but I agree about not wrapping exceptions in general. -- Wade ------------------------------------------------------- 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
