We are splitting up a larger schema into separate databases -- there's a
set of tables that have a very small set of relations to the other tables,
so good candidates for separating out.

Of course, w/o the tables all in a single DB the joins have to be done in
code.

We are looking at using PostREST (https://github.com/begriffs/postgrest)
which places a REST API on top of Postgresql.

We have a fair amount of business logic in the DBIC result (and resultset)
classes, so the question is if we can reuse this code directly.   For
example, would it be possible to write a Storage layer that instead of
talking to a DBI connected database one that is access via by HTTP.

Are there examples of non-DBIx::Class::Storage layers?   Does that even
make sense in DBIC context?


I'm also not convinced that PostREST makes sense.   Why talk to the DB via
HTTP instead of using DBI directly?   To make it useful we would need to
put much more business logic into the database as views and stored
procedures.   And that feels like going back in time to when DBAs were
gatekeepers on every change and access to the DB.    Anyone else looked at
this?


-- 
Bill Moseley
mose...@hank.org
_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk

Reply via email to