Re: [Catalyst] API Versioning for Web Services
On Sun, Jul 27, 2008 at 06:42:23PM -0500, [EMAIL PROTECTED] wrote: widget.1.get widget.2.get etc. Icky, I think the API should be versioned -- not methods. What if the methods across versions are not compatible (widget1 output used with foo2) versioning the api forces all methods to be used with their tested and versioned partners. When you have 30 or 40 different revisions and developers start relying on mismatching methods from different versions that seems like a headache waiting to happen. I completely agree. I suppose a version XMLRPC parameter in the request payload is possible, but I'm actually leaning more toward just using separate endpoints: http://localhost:3000/rpc1.2 http://localhost:3000/rpc1.3 or http://localhost:3000/rpc/1.2 http://localhost:3000/rpc/1.3 or http://localhost:3000/rpc?version=1.2 -- Bill Moseley [EMAIL PROTECTED] Sent from my iMutt ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Duplicate entries with C::P::Session::Store::DBIC and MySQL
Hi list, I've written about this at least once in the past and still haven't been able to figure out a proper solution to the problem. We're getting loads (up to 30-40 per day) of the following fatal error: Duplicate entry 'flash:***' for key 1 [for Statement INSERT INTO sessions2 (id) VALUES (?) with ParamValues: 0='flash:***'] at /usr/local/lib/perl5/site_perl/5.8.8/Catalyst/Plugin/Session/Store/DBIC/Delegate.pm line 52 I suppose that most of you are never seeing this error because you're using a) a sane database with proper transactions (although I'm unsure DBICs find_or_create makes use of them transparently). I'm (at least for the moment) stuck with MySQL and a MyISAM session table. Yeah, I know ... b) a storage backend that doesn't bother if there are duplicate entries (FastMmap, Memcached, File, etc) and just overwrites. The cause obviously seems to be concurrent requests by the same user - mostly the impatient F5-hitter-type :)) So what happens is basically: 1) Request 1 comes in, selects for a flash-entry in the session table and doesn't find anything. 2) Request 2 comes in, does the same and comes back with empty hands, too. 3) Request 1 inserts its flash values into the table. 4) Request 2 tries to do the same, fails and the user gets a fatal error message although nothing _that_ bad happened :( Now, I know that the time window for this to happen is supposed to be quite small but the amount of errors I'm getting is worrying. So, IMHO the error should be handled by the application in a more gentle way (as opposed to throwing a fatal error) because AFAICT nothing bad will happen if the session data is just overwritten (which is what most other P::Session backends will do anyway). Is there anything speaking against wrapping line 52 of the DBIC backend class with an eval to trap this duplicate error and ignore it silently (or just warn about it) except the fact that it's trying to fix something that probably should be the database's task? Note that only the flash is causing this problem - I haven't had a single error with just the session stuff. --Tobias ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Duplicate entries with C::P::Session::Store::DBIC and MySQL
Quoting Peter Flanigan [EMAIL PROTECTED]: Tobias Kremer wrote: Duplicate entry 'flash:***' for key 1 [for Statement INSERT INTO sessions2 (id) VALUES (?) with ParamValues: 0='flash:***'] at /usr/local/lib/perl5/site_perl/5.8.8/Catalyst/Plugin/Session/Store /DBIC/Delegate.pm line 52 What is the length of the id field in the sessions2 table? Is it longer than a session key? Yes, it's a char(72) field which is what the POD recommends: http://search.cpan.org/dist/Catalyst-Plugin-Session-Store-DBIC/lib/Catalyst/Plugin/Session/Store/DBIC.pm#SCHEMA This is a different problem than the one discussed last week or so! I'm pretty sure it's a classic race-condition. --Tobias ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Duplicate entries with C::P::Session::Store::DBIC and MySQL
Tobias Kremer wrote: This is a different problem than the one discussed last week or so! I'm pretty sure it's a classic race-condition. Then I would suggest placing a lock around the critical region of code. IPC::SRLock perhaps (which I wrote) -- Regards ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] API Versioning for Web Services
On Sun, Jul 27, 2008 at 09:09:46AM -0700, Bill Moseley wrote:
On Sat, Jul 26, 2008 at 06:00:39AM +0100, Matt S Trout wrote:
sub widget :Local VersionedXMLRPC('widget.get') {
sub widget_xmlrpc_v1 {
have VersionedXMLRPC apply a custom a ction class that does -can
based dispatch, same way Catalyst::Action::REST does.
C::Action::REST uses ActionClass('REST') to specify the class for
the action. And with a custom request class, has a custom dispatcher to
dispatch based on the request method.
Your example above does not use ActionClass. Were you suggesting that
these XMLRPC actions have their own action class, and if so how would
the actions be setup then?
My example suggests you write _parse_VersionedXMLRPC_attr to apply
the action class etc.
By the way, my assumption is I would have the entire XMLRPC API
versioned. I asked about this on the XMLRPC list and it was
recommended that instead I version individual methods. That is, have
separate method names that include a version:
widget.1.get
widget.2.get
etc.
which would make the Catalyst part very simple, but I'm not sure I
like that idea of each method having a version in the method name.
I'd suggest a header, really. X-MyApp-XMLRPC-Api-Version: or similar.
Makes the versioning stuff optional, thus simplifying the simple case.
--
Matt S Trout Need help with your Catalyst or DBIx::Class project?
Technical Directorhttp://www.shadowcat.co.uk/catalyst/
Shadowcat Systems Ltd. Want a managed development or deployment platform?
http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Squatting::On::Catalyst
On Mon, Jul 28, 2008 at 08:27:27AM -0700, John Beppu wrote: *Squatting::On::Catalyst* Squatting is a web microframework for Perl that's based on Camping from the Ruby world. During the transition from Ruby to Perl, Squatting gained some mutant powers which is why I'm writing to you today. One of Squatting's mutant powers is its ability to embed itself into other frameworks (like Catalyst). You can take whole Squatting apps, and embed them into your existing web application with just a few lines of glue code. Allow me to demonstrate. Assuming Squatting supports CGI, Catalyst::Controlle::WrapCGI enabled this already. Your code is almost certainly more efficient though. *What Are The Implications of This?* Right now, anyone who is developing a web app with Catalyst can install Pod::Server from CPAN and embed it directly into their web app. However, this is just the beginning. Imagine if you could install a blog, a wiki, a forum, or a store just as easily. Yeah, we'll be doing that for arbitrary Catalyst components for 5.80, I hope. This is still really cool, mind. In the meantime, please have a look at the HTTP::Engine project so that you can share HTTP code with other frameworks, and consider joining the catalyst-dev list since we're planning to kick off a project to see about sharing dispatchers with other projects as well. -- Matt S Trout Need help with your Catalyst or DBIx::Class project? Technical Directorhttp://www.shadowcat.co.uk/catalyst/ Shadowcat Systems Ltd. Want a managed development or deployment platform? http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Squatting::On::Catalyst
On Mon, Jul 28, 2008 at 2:40 PM, Matt S Trout [EMAIL PROTECTED]wrote: On Mon, Jul 28, 2008 at 08:27:27AM -0700, John Beppu wrote: Imagine if you could install a blog, a wiki, a forum, or a store just as easily. Yeah, we'll be doing that for arbitrary Catalyst components for 5.80, I hope. This is still really cool, mind. Good luck w/ that. I don't know the guts of Catalyst too well, but I have a feeling it could be tricky. In the meantime, please have a look at the HTTP::Engine project so that you can share HTTP code with other frameworks, and consider joining the catalyst-dev list since we're planning to kick off a project to see about sharing dispatchers with other projects as well. HTTP::Engine was exactly what I needed when I started the project. I'm glad I know about it, now. -- Matt S Trout Need help with your Catalyst or DBIx::Class project? Technical Director http://www.shadowcat.co.uk/catalyst/ Shadowcat Systems Ltd. Want a managed development or deployment platform? http://chainsawblues.vox.com/ http://www.shadowcat.co.uk/servers/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
