Chris Withers writes:
Clemens Robbenhaar wrote:
But it is a base exception class in ZOracleDA, however. Thus the product using it need to explicitely import this exception, and thus explicitely depend on the used relational database; code needs to be rewritten if one exchanges the external data base.
So, you got sucked into the myth of SQL too? ;-) You'll need to rewrite at least some of your SQL if you change backends, so I don't see this as a huge problem...
Well, except if migrating _from_ mySQL, whose features are usually covered by all other sql data base implementation (some kind of upward compatibility ;-) (No pun on mySQL, I personally do not like to see more features than a non-expert can keep in mind anyway ... the sql experts may disagree on this, of course ;-) Actually my code just contains some few "select foo from bar" statements, so it most probably will not change when migrating the data base. But I see, my case seems to be a very specific one, and if the sql-db is migrated I will survive having to change a few lines ...
Well, um, yes, at least I am asking if it makes sense to keep the exception DA.DatabaseError in the code, even it it is not yet / no longer used.
I think it's good ot keep it there so DA authors can subclass it, but not for stuff to be caught and re-raised as is happening now...
As I understand we agree on the original point of the discussion. Cheers, Clemens