Re: Session directories in 0.9.6
On Aug 23, 2007, at 6:16 PM, Mike Orr wrote: At some point I got a DeprecationWarning that all cache_ variables should be changed to cache.. Looking back, it must have been cache_enabled that triggered it. So I changed the underscores to dots, and later noticed a None directory in my application, containing container_lock files that looked like they belonged in the data directory. I deleted the None directory and it came back. So i created an empty directory with no access permissions to force an exception, and got: The beaker.cache. and beaker.session. beginnings are ideal. The None directory bug was fixed, and release 0.7.5 has the fix in it. There should be a beaker.cache. directive, alternatively, cache_dir should still be fine. Cheers, Ben smime.p7s Description: S/MIME cryptographic signature
Re: 'c' variable between redirects
Tomasz Nazar wrote:
On 8/24/07, *Christoph Haas* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
As I understand 'c' is always reset before any controller's
action - what is
not fun for me, as in my app one user request/click is often 2
(or more)
Pylons controllers' actions, hence http redirects..
Without knowing your application I dare say that this sounds like you
are using redirect_to in the wrong places. If the application is
supposed to do multiple things when a user does a certain HTTP request
then why can't one controller's action do that alone?
Christoph
Simple said, because of the duplication of some parts of the code.
Let's have this example from my app for discussion:
Usecase 1: Go to Home Page - issues 'controller: home/home' -
renders 'home.mako'
Usecase 2: Send email to a friend, and show Home Page - issues
'controller: email/send', then redirects to 'controller: home/home' -
renders ' home.mako'
Of course 'home' action of controller 'home' does some specific logic,
like showing current user's data from DB. That is a reason, I just
can't show 'home.mako' in 'email/send' page after sending an email.
And it is really bad to implement that logic twice in different places..
Rather then using return redirect_to('home') in your email controller,
why not just call home directly return self.home(), of course that
assumes that home and email are in the same controller which they might
not be, but you should be able to simply import what ever actions you
need from waht ever controllers you you've already written. Or did I
miss something very fundamental in the the conversation?
Jose
Though I sometimes handle such situations by just _calling_ (not
redirecting) 2nd action from a controller, only when 2 actions used
are in the same controller.
Hmm...however when I think about that now, I think I could also not to
redirect, but could try to call 'home/home' action from another
controller ('email') class/object.. could I? Can I access that object
somehow?
Tomasz
ps. session is somehow too global for my needs. That's 'c' is the
thing to use I think
ps2. In Java/Struts I've used forms for storing that kind of data,
that is nor sesion global, nor http request specific.
--
_i__'simplicity_is_the_key'__tomasz_nazar
_ii'i_am_concern_oriented'JKM-UPR
_iii__'patsystem.sf.net http://patsystem.sf.net
'___linux_user
_'aspectized.com
http://aspectized.com'___prevayler
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Trouble with Routes
On Aug 24, 2007, at 2:56 AM, Dan Korostelev wrote: Yeah, I also worked around the problem this way, but I don't like it. Looks like there's a bug in Routes. Thanks for information. There's no bug in routes, this is exactly how it works, and how the docs indicate it works. From the docs (http://routes.groovie.org/ manual.html): We saw earlier how the route name ties a set of defaults to a name. We can use this name with our Route functions and its as if we used that set of keyword args The route name does *not* mean that the route its at will actually be the path generated. It means that the default args you give for that route will be pulled in as if you had specified them in the url_for. Cheers, Ben smime.p7s Description: S/MIME cryptographic signature
Re: implementing a scalable (to multiple processors and multiple servers) Pylons webapp
On Aug 24, 2007, at 4:15 PM, Cliff Wells wrote: Memcached seems the easiest (and probably best) solution. As Philip mentions, however, it isn't well-documented how to use Beaker with Memcached. If you decide to go this route, maybe update the wiki? I'd highly suggest memcached rather than database backend. It's easy to setup, and of course, very fast. :) Here's the setup info for memcached: beaker.session.type = ext:memcached beaker.session.url = 192.147.32.2 The url can be a comma separated list of IP/hostnames as well should you be using multiple memcached servers. Cheers, Ben smime.p7s Description: S/MIME cryptographic signature
Re: implementing a scalable (to multiple processors and multiple servers) Pylons webapp
On 8/25/07, Ben Bangert [EMAIL PROTECTED] wrote: I'd highly suggest memcached rather than database backend. It's easy to setup, and of course, very fast. :) Yes, but as far as I know, memcached objects can be always replaced, that is, you cannot define an object to be persistent, can you? Thus, one also needs to back up the session data to a persistent storage so it does not get replaced when the cache fills up. Here's the setup info for memcached: beaker.session.type = ext:memcached beaker.session.url = 192.147.32.2 The url can be a comma separated list of IP/hostnames as well should you be using multiple memcached servers. Thank you. This helps, but still, I need to define the persistent storage in addition to the memcached due to above mentioned reason. -- --PJ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: 'c' variable between redirects
On 8/25/07, Jose Galvez [EMAIL PROTECTED] wrote:
Tomasz Nazar wrote:
On 8/24/07, Christoph Haas [EMAIL PROTECTED] wrote:
As I understand 'c' is always reset before any controller's action -
what is
not fun for me, as in my app one user request/click is often 2 (or
more)
Pylons controllers' actions, hence http redirects..
Without knowing your application I dare say that this sounds like you
are using redirect_to in the wrong places. If the application is
supposed to do multiple things when a user does a certain HTTP request
then why can't one controller's action do that alone?
Christoph
Simple said, because of the duplication of some parts of the code.
Let's have this example from my app for discussion:
Usecase 1: Go to Home Page - issues 'controller: home/home' - renders
'home.mako'
Usecase 2: Send email to a friend, and show Home Page - issues
'controller: email/send', then redirects to 'controller: home/home' -
renders ' home.mako'
Of course 'home' action of controller 'home' does some specific logic,
like showing current user's data from DB. That is a reason, I just can't
show 'home.mako' in 'email/send' page after sending an email.
And it is really bad to implement that logic twice in different places..
Rather then using return redirect_to('home') in your email controller, why
not just call home directly return self.home(), of course that assumes
that home and email are in the same controller which they might not be, but
you should be able to simply import what ever actions you need from waht
ever controllers you you've already written. Or did I miss something very
fundamental in the the conversation?
Jose
That is exactly what I was thinking of during writing my reply.. (see
below).
If it works I could like it..
Though I sometimes handle such situations by just _calling_ (not
redirecting) 2nd action from a controller, only when 2 actions used are in
the same controller.
Hmm...however when I think about that now, I think I could also not to
redirect, but could try to call 'home/home' action from another controller
('email') class/object.. could I? Can I access that object somehow?
Tomasz
--
_i__'simplicity_is_the_key'__tomasz_nazar
_ii'i_am_concern_oriented'JKM-UPR
_iii__'patsystem.sf.net'___linux_user
_'aspectized.com'___prevayler
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: implementing a scalable (to multiple processors and multiple servers) Pylons webapp
On Sat, 2007-08-25 at 20:24 +0300, Pekka Jääskeläinen wrote: On 8/25/07, Ben Bangert [EMAIL PROTECTED] wrote: I'd highly suggest memcached rather than database backend. It's easy to setup, and of course, very fast. :) Yes, but as far as I know, memcached objects can be always replaced, that is, you cannot define an object to be persistent, can you? Thus, one also needs to back up the session data to a persistent storage so it does not get replaced when the cache fills up. This is a good point and is reiterated here: http://www.socialtext.net/memcached/index.cgi?sessions Regards, Cliff --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: SQLAlchemy tutorial split into 0.4 and 0.3 versions
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'srecommended 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
Re: SQLAlchemy tutorial split into 0.4 and 0.3 versions
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'srecommended 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 -~--~~~~--~~--~--~---
Re: SQLAlchemy tutorial split into 0.4 and 0.3 versions
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'srecommended 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 -~--~~~~--~~--~--~---
