On Thu, May 01, 2008 at 08:41:26AM +0200, Zbigniew Lukasiak wrote: > On Thu, May 1, 2008 at 6:23 AM, Toby Corkindale <[EMAIL PROTECTED]> wrote: > > On Wed, Apr 30, 2008 at 11:24:36AM +0200, Zbigniew Lukasiak wrote: > > > Hi Toby, > > > > > > I don't know if you are aware - but building a REST-like CRUD > > > interface to DBIx::Schema is my long term goal (started with > > > Catalyst::Example::InstantCRUD). Do you think we could collaborate? > > > > Sure, if you liked. > > > > I'm not sure I want to aim for total DBIx::Class:Schema emulation, as I > > think there are many corner cases which could start getting hard to > > implement /well/. > > > > I'd rather approach creating something which does a sub-set of the > > features, but does them well. For instance, how would you handle > > transactions? Or > > My understanding is that you can nest transactions in DBIC - so my > plan is just add a transaction wherever I think it is needed.
Ah, I was thinking of transactions vs a REST API, eg: PUT /user/1234/account_balance?subtract=1 POST /user/4567/account_balance?add=1 Since those are two separate HTTP requests, and REST specifically states you cannot maintain state on the server, how would you perform those two operations inside a transaction? (My "solution" is to implement it in one request, like: PUT /user/1234/money_transfer?user=4567;amount=1 However that is not CRUD-like, nor a direct mapping of DBIC functionality to REST) > > specifying complex searches with aggregate clauses and self-joins? Those > > would seem to be more suited to an RPC protocol rather than an > > object-based REST situation. I think? > > I admit that my main goal is mostly a kind of browser-REST (but with > the option for 'real' REST) - so I start with HTML forms (for now I > discovered Rose::HTML::Form - and I like it) that would define the > available searches. I guess this might look restricting for you. By > the way have you seen my Advent article: > http://catalyst.perl.org/calendar/2007/16 ? Oh, right. I'm definitely making a 'real' REST interface; I'm basing it around a DBIC Schema for the moment, but I'm not attempting to provide 100% of the DBIC features via REST; I figure if you want that, you can just use a real DB connection. Instead I'm trying to provide a simple set of basic REST calls, and a framework for dealing with foreign keys, and then allow extensions on top of that for things such as the example above where you can't use simple calls. I think it sounds like we're really working towards fairly different goals at the moment. Whereas you're looking at using forms and validation there, I'm more interested in having a DB which provides the validation via constraints and stored procedures, and using Catalyst as a fairly thin layer to access it and provide extensions via the DBIC-SChema class. The REST API has proven quite cute when used against a quickly hacked-up pure javascript web UI though; it's blindingly fast compared to having pages built and served and rendered! Toby _______________________________________________ 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/