On Mon, Sep 29, 2008 at 10:28 AM, Florent Aide <[EMAIL PROTECTED]> wrote: > > On Mon, Sep 29, 2008 at 6:06 PM, Christoph Zwerschke <[EMAIL PROTECTED]> > wrote: >> >> Jorge Vargas schrieb: >>> As for the original poster question. The best tutorial about >>> declarative is SA docs themself, but as it's implied in the docs you >>> should learn SA with the "classical" way, and use declarative just >>> when you are comfortable with what and how SA does. In fact the 0.5 >>> docs show you first the set of "classical" instructions and then they >>> show you a way to use declarative. >> >> Our main problem is that TG is using SA's contextual mapper, which is >> more convenient than the standard mapper. But the declarative usage >> works with the standard mapper which is convenient enough in this case. >> And the old contextual mapper, though it still works, seems to be slowly >> discarded, it is not even mentioned in the 0.5 docs any more. So this is >> certainly confusing for a new user. >>
Which is the problem Christopher Arndt pointed out, but I do think it's in part TGs fault as we jumped into all the alternative mappers trying to make things less complicated. I remember before elixir became a single project they where plans to support 3 or 4 mappers in the quickstart (thank god that didn't happen), so yes this is a direct issue of using something pre-1.0 SA and it's mappers are in a lot of flux, but I kind of think that "plain old" + declarative are going to stay. >> I think what we need is a tutorial on how to use SQLAlchemy with >> TurboGears, its various usage styles, when to use save(), flush(), >> commit(), when not to use all() etc. >> > > And one days we'll have to drop the contextual mapper anyway. I know > some people like the "more simple" usage. I feel that having "simple" > is less important than having "stable". And in SA stable is only the > mainstream mapper, each time we used an extension we had support > problems after a few months. > > I already asked if we could remove contextual mappers but some people > were using them. The problem is that now a lot of people have picked > up those mappers in their code and are relying on them. TG 1.5 could > be a good candidate to break compatibility and propose a migration > strategy to what I call "plain old mappers". > Given that 1.1 is going to be the first to set SA as default you may as well do it there, as anyone using SA with 1.0.x was outside the defaults and therefore accepting that things will break. > What do you all think? I know breaking compatibility is hard but SA is > (somewhat) responsible for it, and I don't want to be stuck with an > old package just because we did not want to break some code out there. > I agree with that, if the upstream is responsible of breaking then we need to pass that along, because it will bring us a lot of troubles to have to explain to people that we are using the older version and that the new one isn't supported, which is exactly the case of cherrypy. > Florent. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
