I made mention of this in the CB the other day, but didn't get many responses, so I thought I would ask it here to perhaps get a wider audience and set of responses.
I am modifying a copy of DBD::Proxy/DBI::ProxyServer so that instead of specifying the entire server-side DSN on the client side, you instead specify a known name of a handle to a configured DSN on the server side. Using this and implementing the sql section of the configuration to another set of known queries would allow the client to use a DBI compliant data source without needing to have the server-side implementation details available. I am also looking to update the connection / user / query definition sections to make them more able to be isolated from one another.
- Does a client-side DSN along the lines of dbi:Router:hostname=$hostname;port=$port;dsn=dbi:router:$remotename seem like a reasonable interface? [clarification: $hostname and $port are for connecting to the proxy / routing server, not the database -- that is fully configured on the routing server] Is there something (currently) better to base this on than DBD::Proxy/DBI::ProxyServer?
- Does the name seem sensible?
- Should I just try to incorporate this directly into the DBD::Proxy core itself?
- Any other thoughts / previously invented wheels / ideas?
The major use case I have for this is to standardize access to all of the little bits of information I have to use for my applications which currently exist in different data stores (CSV/TSV, SQLite, ldap, ...) in order to migrate them into a more manageable setup without impacting the application code. This type of configuration would also allow for the mockup of a testing set of data, migration to different platforms, ...
Updates
- pgbouncer was mentioned as a similar tool
- Added description of my use case
- Added a clarification of what the host/port refer to
--MidLifeXis
|
|---|