now I'll have to take a closer look at Session.mapper because it looks
like your implying that is does something other then what the old assign
mapper did. I have a project right now where I'm using Session.mapper
and I've not hit any problems yet. And it does let me do
from model import Mytable
data = Mytable.query.filter(somefield=somevlue)
and stuff like this, but I will take a closer look at the docs to see
exactly what Session.mapper is doing
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 [email protected]
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
-~----------~----~----~----~------~----~------~--~---
