On Aug 22, 2007, at 10:16 PM, Mike Orr wrote:
I'm using Session.mapper in my application and find it superior to the regular mapper.According to the page history, Mike Bayer took it out to avoid confusing newbies who might think it's"recommended rather than optional. I put it back in with a less inviting wording ("don't try this at home unless you understand it"), because users who *do* know what it is shouldn't have to guess the syntax or scrounge for it.
So, I've got to admit, I'm actually regretting telling Ches that Session.mapper was fine. I talked with Mike, and it turns out I really didn't understand a bunch of the intricacies of Session.mapper vs using the basic mapper function from SA 0.4. As such, if we want to show Session.mapper somewhere, thats fine, but I'm really thinking it's best we advocate the basic usage of mapper.
Users who know how to use Session.mapper might rethink whether they really know what its use implies, because I sure thought I knew what it was doing... If you really know SA so well that you're ready for Session.mapper, then having it in the docs isn't needed. Someone that advanced will have a trivial time with Session.mapper if we've doc'd the basic SA mapper use.
I've taken to using it in a project, and its really made my life easy... because ALL the examples and such of using mapper and mapped objects in the docs actually work! Instead of things being in different locations due to Session.mapper, it all *just works*. The drawback? There's marginally more typing depending on how its done.
In my case, I've actually been doing what Mike Bayer originally suggested, that I shunned. :) I went and did "from model import Session, User, Group" in my lib/base.py. So in my controllers I've done:
Session.query(User).filter_by(name="fred").first() or user = User(**myvalues) Session.save(user) Session.commit() etc.I haven't had any probs noticing that I'm using the db when I see Session, cause I always see .query right after it, or some other clearly non-session related thing happening. Plus, I can easily modify anything exactly as the SQLAlchemy docs say, and it *works*!
Since none of the SQLAlchemy docs assume usage of Session.mapper by default, encouraging new users to use this is asking for more support, since *we* will have to explain how to do it when using Session.mapper, or why XXX didn't work due to it, etc.
My final conclusion, for all SA 0.4 docs, show and use the default mapper, not Session.mapper. This will reduce our support requirements, reduce user annoyances (since stock SA docs will all actually work!), and if people want to have it even easier they can use Elixir. If users really hate to see Session for the SA session, you could always "import model.Session as dbsession" or whatever makes them happy, but I don't think it'll be as big of a deal as I originally thought it would be.
Cheers, Ben
smime.p7s
Description: S/MIME cryptographic signature
