> That's terrific! I've been meaning to get involved with SQLAlchemy > (specifically with this particular task). I'm glad someone was able > to do it.
Then, get involved! I would love to have someone else work on this code with me. Anyone who would like to, just ask, and I will give you commit access to the repository. > I'm definitely keen to try this out, because I keep banging my head > against SQLObjects' severe limitations. Indeed. I find that SQLObject is a brilliant piece of work, and I don't want to knock it really. It works like a champ for lots of cases, and I think its a good choice for a decent number of projects. However, SQLAlchemy can do a lot more, and hopefully soon it can be just as pretty and simple to get started with. > I think what impressed me most is that Michael Bayer wants > SQLAlchemy to work for everyone not just people who do databases > *exactly* like he does. My personal hot button: SQLObject is > basically worthless accessing any database that doesn't use integer > primary keys. That leaves out GUID primary keys. That leaves out > composite keys. That leaves out dependant keys. That leaves out > *the majority* of the databases I want to access. I totally understand your complaints, and hopefully this declarative layer will help make SQLAlchemy an even better choice for you. > Thanks for getting this underway, Jonathan. No problem! -- Jonathan LaCour http://cleverdevil.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~----------~----~----~----~------~----~------~--~---
