Paul Johnston ha scritto:
Manlio,
I quite like your idea, although I also agree with Michael's "no magic"
philosophy. I identified a similar problem with autoincrementing primary
keys, where a model that worked with one db (say sqlite) would not work
with another (say oracle).
All libraries that try to provide portability have this problem
(windowing libraries are a notable example). You could only provide the
subset of functionality that works on all the supported databases. Or
you could provide functionality that only works on some databases,
meaning it's possible to create non-portable code that only uses the
"portability" library (this is SQLAlchemy's approach). The third option
is to have the library "fake" the functionality on databases that don't
support it.
Well, Michael has said he doesn't want the third approach in SA, but I
guess there's nothing stopping someone creating an extension to do this.
If you feel strongly, go ahead and have a go!
An extension is a good idea, but is this possible?
I'm not an expert of the sqlalchemy's internals
Regards Manlio Perillo
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
