On Friday 28 July 2006 11:13, Oleg Broytmann wrote: > > I've discovered that the Database API Specification v2.0 is followed > > by both MySQL and > > SQLite Python modules, so all that need to be done in this case was a > > one-to-one mapping between > > their exceptions and the SQLObject defined ones. > > I am not so sure about one-to-one mapping. On a duplicate inserts > Some DB drivers raise ProgrammingError, some raise OperationError, some > IntegrityError. This is what we'd like to unify in a consistent set of > SQLObject's exceptions.
I think you misread that. He said that the MySQL and SQLite have 1 to 1 mappings. As for other backends, I have no idea. Each db backend will will have its own mappings, from the backend exceptions to the SQLObject exceptions. It happens both MySQL and SQLite follow the pep and the mapping is 1 to 1. I have no idea what exceptions other backends raise, so in their case the mapping may not be 1 to 1, but I don't see how this matters, as each backend will map the exceptions as it has to internally and raise the set of standard SQLObject exceptions. > > > Index: sqlite/sqliteconnection.py > > =================================================================== > > > > +class ErrorMessage(str): > > + def __new__(cls, e): > > + obj = str.__new__(cls, e[0]) > > + obj.code = None > > + obj.module = e.__module__ > > + obj.exception = e.__class__.__name__ > > + return obj > > + > > These classes are too similar. Are they really two different > classes? Not really, but each db backend has to initialize them in a very specific way, depending on its internals. They are just some internal thing, defined by each db backend as it fits the backend's needs. I find it easier that each backend defines that class internally and passed the backend exception to it, to transform it into a SQLObject error message, than to have a single common class that will require multiple parameters to initialize. Anyway, it doesn't really matter much as they are just a standard python string with some attributes (to identify the original exception if there is a need). For all it matters to the exception handler they are a string. Their purpose is to have a string (the error) with some extra attributes (for debugging and extending purposes), not to have it interpreted like a new class. Exception handler should handle them as strings with attributes. In the future after the SQLObject exceptions reach their maturity and won't need changes anymore, they can be replaced with simple strings (or maybe not). This was done this way, because you cannot attach attributes to standard python strings, and the point is to return some string with attached attributes, for which I don't really care what's its class, all I care is that it behaves like a string. > > > Index: mysql/mysqlconnection.py > > =================================================================== > > > > +class ErrorMessage(str): > > + def __new__(cls, e): > > + obj = str.__new__(cls, e[1]) > > + obj.code = int(e[0]) > > + obj.module = e.__module__ > > + obj.exception = e.__class__.__name__ > > + return obj > > + -- Dan ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ sqlobject-discuss mailing list sqlobject-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
