On Thu, Jan 15, 2009 at 11:34 PM, 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. >
I'm sorry but you are late to this argument several years, SO -> SA was decided at least 2 years ago. You are probably one of the flew users that still uses SO. I monitor this mailing list daily and we barely see a SO question these days. >> 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. > Trust me it is, in template/ORM you have 1-1 equivalents, in backend you simply don't. Most things works completely different (URL dispatcher, sessions, "tools"/"filters" simply don't exist, many more) > 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. > again it shouldn't take you more than a day. Just out of curiosity how many SO classes/queries do you have? >> 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. > mailing list traffic, only one maintainer, as for the bug reports I don't share the felling back when SO was default in TG, many bug reports where answered with "please provide a plain SO test", that was when we asked for cooperation. Don't get me wrong Oleg is a great guy and his support is great, I don't complain about that but the reality is in place. On the other hand SO has very hard design issues, I won't number them he was that is OT, but none of those are present in SA. >> 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. > No it is hard to work with, SO has the bad reputation of making complex things close to impossible. One example use a pre existing DB, another have a table with no id. >> 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). > as far as I can tell none of the current core developers has a strong investment in SO, therefore it's not on their interest to do so. That said if you are serious about this we'll get you setup with svn access + provide all the help needed so you will become a core contributor and maintain the SO related code. >> 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 :) I don't have the final say but no, this was the biggest problem TG1 had. I won't dedicate time to support it, write docs, write tests, port features, etc, etc, etc. A tgext.sqlobject project is a good compromise it will love as long as people will use it, it won't confuse TG goals or marketing or users. > > Cheers, > Daniel > > -- > Psss, psss, put it down! - http://www.cafepress.com/putitdown > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
