> just me. I can't label SQLAlchemy *the* ORM for TurboGears until it > handles the easy cases easily, has backwards compatibility for people > who started with SQLObject and want to move up, and has support of the > Toolbox and tg-admin.
Won't hold my breath for that. :-) > Does that seem reasonable? Yes, all makes sense. I suppose as an end user/app writer I'd have been happier if SQLObject was having it's warts treated on an incremental release basis. I don't know if it was so broken that it needed a complete rewrite rather than staged refactoring. That means SQLObject2 is going to need a good deal of testing and running-in before it's ready for use in production systems. Quite a way of I think. Cheers, Justin > > From: "Kevin Dangoor" <[EMAIL PROTECTED]> > Date: 2006/03/16 Thu PM 03:25:54 GMT > To: [email protected] > Subject: [TurboGears] Re: TurboGears ORM status > > > Hi Justin, > > On 3/16/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Alternatively, SQLAlchemy looks very nice indeed - feature rich and > > powerful. But if Kevin wants to keep SQLObject in the picture then I feel > > that for my part moving to it isn't helping the TG effort. It's harder to > > evangalise the framework if you have to say that you ripped the ORM out > > because it wasn't up to scratch. > > You raise good points, and I'll need to figure out a good way to spell > this out on the website somewhere. > > Here's the complete picture: > > * SQLObject has warts. Everyone, including Ian, is aware of that. But, > it's also very easy to use for the cases that it handles well and it's > in relatively wide usage. > > * SQLAlchemy handles more cases with more grace than SQLObject does. > > * SQLAlchemy does not yet have an API that is as easy as SQLObject's > in the cases that SQLObject handles well. The ActiveMapper extensions > bridges this to a large degree. > > * SQLAlchemy is not yet considered stable by its author (Mike Bayer). > And yet, Mike is also aware that people are already using it and many > are using it to good advantage. > > * TurboGears does not yet have a compatibility layer to ease the > transition to SQLAlchemy. > > * TurboGears currently has support for using SQLAlchemy on the trunk. > This will appear in 0.9a2. It doesn't cover things like the Toolbox. > > If I was starting a new project today, I would use SQLAlchemy and deal > with the API instability and lack of additional tools. But, that's > just me. I can't label SQLAlchemy *the* ORM for TurboGears until it > handles the easy cases easily, has backwards compatibility for people > who started with SQLObject and want to move up, and has support of the > Toolbox and tg-admin. > > It is for these reasons that TurboGears 1.0 will ship with SQLObject > as the "official" ORM. But, the support is there for SQLAlchemy for > people who are working outside the bounds of what SQLObject handles > gracefully. > > Does that seem reasonable? > > Kevin > > > ----------------------------------------- Email sent from www.ntlworld.com Virus-checked using McAfee(R) Software Visit www.ntlworld.com/security for more information --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
