Re: Pylons, sqlalchemy db awareness
Maybe I can rephrase this more simply. I want to know if my pylons/ sqlalchemy session has realtime knowledge of the database it is working with, or if the only way to achieve this is through a stored procedure or constant polling. -joe On Nov 10, 4:57 pm, kettle [EMAIL PROTECTED] wrote: Hi, I am new to pylons/sqlalchemy, and not sure whether this question belongs in a sqlalchemy forum or this pylons forum but... basically I'd like to know what kind of awareness the sqlalchemy model for my pylons application has of the database. Specifically, does it have any kind of realtime knowledge of the database with regard to table updates or row insertions? If I want to know about updates to the database (many of which are coming from remote clients) and convey this information or log it in my pylons application, is there any way to do this without constantly polling the database, and if possible, also without implementing a trigger in the db, or an in memory copy of the latest updates/insertions? If sqlalchemy already has this awareness, how can access it/leverage it for my application? -joe --~--~-~--~~~---~--~~ 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: UNS: Re: cleaner ToscaWidgets
Matt Feifarek wrote: On Oct 24, 2007 5:06 PM, Alberto Valverde [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Yep, was planning to do that when I cover tweaking the layout. Finally didn't have time to start part 2 today but will tomorrow... Hey Alberto -- did a part 2 ever fall out of your brain? No, not yet. I've wish I could spare an afternoon sometime soon to do it but I doubt it because I'm pretty busy at the moment. Sorry. We're eager to learn more about TW, and are having some troubles getting beyond the simple examples to our own custom fields and templates. Your best bet at the moment is to search the archives of toscawidgets-dicuss google group and/or study the templates of twForms' fields and forms. Alberto --~--~-~--~~~---~--~~ 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: Must WSGI Applications Respond to Requests?
Mike and Graham, Many thanks for your replies. Glad to see the subject has some general interest. Graham: The closest you can get is to use 404 or some other HTTP status. Yes, I did see in Cascade where you can configure which HTTP statuses are used for signaling. So when overloading 404 isn't OK, perhaps 501 Not Implemented could be used. OTOH, one could envision situations where that status needed to be retained for its true use. Leading to... Graham: I too see the ability to cascade as possibly useful, but that one has to overload on the return status as not being ideal. Agree there. One of my colleagues would say this overloading creates cognitive friction, by using one thing to mean something else. Maybe a pseudo HTTP response (599 Not My Job), or even forget the HTTP part and raise a custom NotMyJobException that the cascade manager catches? Mike: You don't have to use Cascade. It exists only because people want to overlay controllers and static files in the same URL space. I wasn't even including static file serving, but I can see the point, as the same middleware stack could apply to each. In our case, we have two substantially separate applications but with the same user base and security plan, such that they will share common middleware. Obviously we could instead just wrap each application with the same middleware combination--and we may do this--but there appear to be benefits to combining them in a cascade-like scenario. Thus our interest. Graham: I was querying about the same sort of functionality back in 2005...See: http://mail.python.org/pipermail/web-sig/2005-July/001519.html http://mail.python.org/pipermail/web-sig/2005-July/001525.html Good reference. Thanks. Mike: But if you start thinking about Python apps inside a Python app, that's something that's just starting to be discussed. The thread Sites within sites two weeks ago has more info. Basically we've come up with a couple strategies that might work but nobody has tested them yet. This is interesting and, oddly, it feels good that the discussion is just getting started. Apps within apps, at least in WSGI space, could be workable. Maybe a framework could provide general support for an app containing sub-apps. When an app gets called, it gives its children (if any) each a shot (like Cascade) and if none of them act, the parent takes its shot. Just musing. -- Randy --~--~-~--~~~---~--~~ 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: db update notifier for pylons app
Hi Folks, On Nov 7, 2007 5:33 AM, Marek Stępniowski [EMAIL PROTECTED] wrote: You could use a Comet approach (http://en.wikipedia.org/wiki/Comet_%28programming%29). Look at Orbited (http://orbited.org/) which makes it pretty easy. Orbited has bindings for Python and can be integrated with Pylons (http://orbited.org/tutorials/pylonschat.html). Note well: The orbited team has just released orbited 0.2, which changed a bit from the orbited 1.x releases, so there are some gaps between the documentation and implementation. The orbited team has provided some excellent tools for doing comety things. They're also friendly and enthusiastic about helping people use orbited to solve their problems. Should you run into any, try their mailing list or livehelp demo application. Regards, Matthew --~--~-~--~~~---~--~~ 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: Utility scripts
Mike Orr wrote: We've often discussed but never resolved where to put standalone scripts and cron jobs related to a Pylons project. These might be for database maintenance, data import/export, ad hoc scripts you might use again someday, etc. Pylons apps don't have a 'bin' directory or executable; everything is hung off 'paster' (or possibly a 'pylons' command at some time in the future). This seems to leave two possibilities: 1) Scripts registered in setup.py for the global 'bin' directory. A standard package for these would be good, perhaps myapp.util, myapp.scripts, myapp.standalone, or something like that. Similar to a script, in Python 2.5 you can do: python -m package.script And it'll be equivalent to: python path/to/package/script.py In Python 2.4 this only works for top-level modules. 2) Paster plugins. Apparently you can add a Paster command with an entry point like: [paste.paster_command] mycommand = package.module:Class However, I'm not sure how Paster would know which egg to look for paster mycommand in, unless the current directory is the application. Putting these globally in Paster when they're really application-specific is also undesirable. There's a different entry point for global commands. OTOH, to use the local command you either have to use paster --require=Package mycommand, or run paster mycommand from inside the source directory (it looks for some .egg-info directory in any parent directory of the pwd). I don't think this is great for deployed applications, though. Also, most of my utilities require a database connection which implies an .ini file. This makes them *like* paster setup-app both in their command-line syntax, need for an .ini file, and code for reading the configuration (a la websetup.py). Sometimes you also need additional command-line arguments or options. So, which way is better, and has anybody tried making an app-specific Paster plugin? I guess we'll need a HOWTO on both strategies. I'm concerned that it's so complicated to make standalone scripts for Pylons apps that people just work around it, or at least I do, but that's a disadvantage for Pylons. it's something that really should be straightforward and easy and documented. This has kind of been hanging for a long time. I think I'm going to add a command: paster request config.ini / Which will run a request for / against the application described in config.ini. And then, maybe allow the ini file to have something like: [command_urls] /foobar = description of what / does /foobar alias = foobar Then you could do: paster request config.ini -h # get a list of urls in [urls] paster request config.ini foobar # from the alias Though... that's not ideal. Cloning that [urls] section everywhere is a pain. Maybe instead it should have a default URL of /.command-line/, and paster request config.ini -h calls /.command-line/?-h, and paster request config.ini foobar calls /.command-line/foobar. There would be a special key set to mark command-line access vs. web access, so you could restrict access appropriately. This has been a hanging issue for a long time, so it's really something I should just implement. To be nice in Pylons it would also require a Controller subclass that was customized to this kind of usage. -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
DO NOT OPEN
DO NOT OPEN www.chromee.blogspot.com DO NOT OPEN www.chromee.blogspot.com DO NOT OPEN www.chromee.blogspot.com --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
