PostREST

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

PostREST

Bill Moseley
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
[hidden email]

_______________________________________________
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@...
Reply | Threaded
Open this post in threaded view
|

Re: PostREST

Darren Duncan
Bill, why not let Postgres handle this natively?  Postgres can federate
databases, particularly other Postgres databases, so you could let Postgres do
the work you envisage doing application level.  Granted, that may not be the
best option for your situation, but it is one you should evaluate.  Note that it
makes a difference which Postgres version you use, the later the better. --
Darren Duncan

On 2016-06-16 9:02 AM, Bill Moseley wrote:

> 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
> [hidden email] <mailto:[hidden email]>
>
>
> _______________________________________________
> 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@...
>


_______________________________________________
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@...
Reply | Threaded
Open this post in threaded view
|

Re: PostREST

Marco
In reply to this post by Bill Moseley
Excerpts from Bill Moseley's message of 2016-06-16 09:02:10 -0700:

> 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?
>

It seems you have two questions that are unrelated...

1) Database refactoring.
2) Examples of non-DBIx::Class::Storage layers (PostREST).

1) is a design option, 2) is a internal implementation of DBIx::Class

As with any good OO system 2 can be anything that uses the proper
interface, no different with DBIx::Class. Question 1 has many options,
but you must say what is the goal to achieve first, generally database
refactoring will took place for:
1) speedup common users queries
2) apply normalization for data integrity
3) security compliance.
4) application new requirements (new functionalities).

But many others goals may lead you to your design, as with any design
decision you should layout the goals and constraint for each.

Best luck,

Marco

--
Marco Arthur @ (M)arco Creatives

_______________________________________________
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@...