support Replication

[xenoterracide]

DBIC has some nice replication features that would be cool if they could be used in DBIx::Connector. That way it supports all of the connection features of DBIC. http://search.cpan.org/~ribasushi/DBIx-Class-0.08120/lib/DBIx/Class/Storage/DBI/Replicated.pm

[theory]

Replication should never be done at the app layer. It should be done at the database layer. So I am philosophically opposed to such a thing.

That said, there's nothing to stop someone else from adding it in a subclass, or using DBD::Multiplex or something.

[xenoterracide]

how odd.. given that DBIx::Connector is at the database layer IMO not the App layer. But your module.

[theory]

No, DBIx::Connector is at the app layer. Bucardo is something at the database layer: That is, inside the database.

[xenoterracide]

oh if you're talking layers like that... but that's overall system architecture. What I'm talking about is more like PG Pool than Bucardo. I was thinking more within the Layers of the application. DBIx::Connector is at the db or service layer within an application. (also I think my brain is confusing "application layer" due to me having to explain layered architecture to local team. I use it to refer to the Mojo/Dancer/Catalyst app.). In any regard the feature is not to facilitate multimaster or the actual replication, but very simple pooling of servers so your database connection handle can have seperate read/write slaves that are easy to access. e.g. I can ask for read only's and it will select from a pool.

[theory]

Oh, I wouldn't call that replication. Not sure what I would call it… At any rate, I expect it wouldn't be too hard to build something like that on top of DBIx::Connector.

[xenoterracide]

I may have worded it wrong, which is why I linked to the feature in DBIC. Basically it's simplistic pooling for the replicants. It just seems like something that could be extracted and would be useful to extract from DBIC.

[theory]

Maybe, but for pooling, I actually prefer something like pgBouncer. Most of that kind of giggery-pokery at the Perl app level (and by "level" I mean stuff written in Perl and running outside the database, not anything to do with MVC) to be unreliable and error-prone.

Switching between handles for reads and writes is pretty straight-forward, though: just have two database handles (or DBIx::Connector objects).

[xenoterracide]

oh of course you're right, though something in DBIx::Connector native would ultimately be less error prone than things I've seen implemented. (oh god my boss wrote something that was using a single $self->{handle} and had like a set writer / set reader that modified that and on top of it I think this single object was passed everywhere, IIRC ). passing handles is of course possible, I'm just thinking that it'd be nice to flag transaction rw or ro, and have it select from the pool, if the pool is 1 server then you get the same handle. It comes down to the problem of where is the best place to put the "get the right handle" logic. Specifically for 'ease of adding servers' later (I only use one now).

[theory]

I dunno, that feels higher level than DBIx::Connector, but maybe not? Not at all sure, would need to actually work with a system like that to get a feel for the right level of handle selection.

On the other hand, I would might try to use PGPool II and let it figure out what to do with each query.

[xenoterracide]

unfortunately we don't use Pg, so... and our ... CTO? is a changophobe which means he wouldn't want to introduce that layer (no that doesn't make sense)

[theory]

I would not be surprised if there was something similar for your DB.