>>>>> 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.
Okay, I think you've made your point and after all it's reasonable. Honestly, until today I thought what you say is the consensus among developers but then came the comment from Mark that adding SO support to tg2 is not that hard, which made me think that perhaps there is a chance that this will happen. Now I'm back to my previous mindset that it won't happen. Long live 1.x branch (with a possible fork using an extra-mega-cool brand name)! 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 -~----------~----~----~----~------~----~------~--~---
