I think tgext.sqlobject is the way to go here. This package can be included in our index and possibly even installed by tg.devtool...
But I think it should be a septate package for clarity and for maintainsbility reasons. It's not a totally trivial task. But it's not too large either, and as you say SO specific code can be a large part of many apps. So I think it's worth doing.... The only problem I have is that I don't have time to do it. :( On 1/16/09, Daniel Fetchinson <[email protected]> wrote: > >>>> It's clear that the tg team can not make the transition from sqlobject >>>> to sqlalchemy any easier, so I'm definitely not arguing for that. What >>>> I'm saying is that if many users are in the same boat (transition to >>>> 2.x from 1.x would be easy from a framework point of view, but hard >>>> from an ORM point of view because of the sqlobject - sqlalchemy >>>> transition) then perhaps not so much emphasis needs to go into >>>> creating stepping stones such as 1.1 and 1.5. But maybe many other >>>> users are not ORM limited, they perhaps really need stepping stones >>>> for the framework itself. >>>> >> >> You got that wrong. TG1.1 default ORM is SQLAlchemy. And SO is a >> second class citizen there. >> >> The main purpose of TG1.1 (from a migration point of view) is to get >> you in shape for TG2.0 > > My argument is exactly that 1.1 does not help me at all to get in > shape with 2.0. The reason is what I mentioned: the single limiting > factor for me to upgrade to 2.0 is the fact that SO will not work with > 2.0. Again: I'm not at all limited by the cherrypy to pylons > transition because my app rarely uses any cherrypy internals. But it > heavily uses SO and migrating that to SA is hard. > > I believe any 1.x user who uses SO heavily (any data driven app will > be heavily integrated with the chosen ORM) will not be helped by 1.1 > to get in shape with 2.0. > >> Now keep in mind 1.0 can mean several things. Going from "stock" TG1.0 >> to TG2.0 will be a real problem, because you have to change all mayor >> component, (ORM,template and "backend") TG1.1 deals with the two >> simplest, TG2 deals with the complex one. > > You are working under the assumption that the ORM and template changes > are simple while the backend change is hard. I'm telling you that this > can be true for your apps and of course it can be true for many other > people, but not for everybody. For example it's definitely not true > for me and I believe I'm not alone. > > I agree that the template change is really simple, so I'm not talking > about that at all, we are in full agreeement, kid to genshi is almost > trivial. > >> Maybe for you SO->SA is a big transition, but it's nowere near close >> to CP->pylons. > > Again, this depends on the app itself. If it's a data driven app that > doesn't touch any (or only few) CP internals, the CP -> pylons change > is easy and the SO -> SA transition is hard. > >> In fact moving from SO -SA shouldn't be more than a day of work. > > This again depends on the app. If it has complex and extensive use of > SO, this statement is simply not true. > >> Assuming you already learned SA. >> >> Now for people that (like TG1) went deep down into CP2 stuff, which >> was needed for many things, going to TG2 will probably be a hard >> re-write (this is the main reason we are commited to support 1.x in >> 2009), keep in mind I'm talking about BIG apps here. >> >> Therefore I strongly suggest everyone to move to TG1.1 first (or TG1.0 >> + genshi + SA) and then to TG2.0 >> >> On the other hand SQLObject, sadly is a dying framework, > > What makes you say that? Support for SO on the mailing list is among > the best ones I've seen for any open source project. There are > frequent releases in 3 separate branches. Submitted patches get > applied fast, bug reports are dealt with equally fast. > >> it's hard to work with and hard to debug, > > Maybe it's hard to work with for you, but I'm sure you realize that > others might think otherwise. > >> I don't think we should add support for it in the core of tg2. > > I personally would be very happy if support for it is added to tg2. Of > course, if the dev team doesn't think so, I'll live with the 1.x > branch (and hope for a fork). > >> If someone is willing to provide a >> tgext.sqlobject package I'm fine with it, but I strongly disagree with >> it being in the core. > > I'm actively trying to change your mind :) > > Cheers, > Daniel > > -- > Psss, psss, put it down! - http://www.cafepress.com/putitdown > > > > -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~---------~--~----~------------~-------~--~----~ 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?hl=en -~----------~----~----~----~------~----~------~--~---
