Hi, I don't think that is a very workable strategy in the long run :( There > are far to many bogus restrictions in some databases, e.g. Oracle, for > any meaningful program to > be written to work on all platforms w/o support/wrapping/hiding of ugly > details by SA.
This is often a difficulty for libraries that provide a portable layer over different implementations. GUI toolkits are a good example. The library essentially has three choices: 1) Only expose functionality that exists on all the implementations 2) Expose the user to the slight differences between implementations 3) Expose consistent functionality, and where an implementation lacks support, fake it In practice, (1) is usually a poor option as it's too restrictive. SQLAlchemy currently takes approach (2). There is definitely consistency merit for approach (3), but it comes at a cost - there's more "magic" going on, which could be confusing in some circumstances. Paul --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
