Ben, I've just read the Session.mapper docs and I'm not sure what your
concerns are. Are you concerned with its use? or that putting it in the
tutorial will confuse new users?
Jose
Ben Bangert wrote:
> 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
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---
