Hi,
Is there any news on this update to DBD::Multiplex?
Thanks,
Adam
----- Original Message -----
From: "Tim Bunce" <[EMAIL PROTECTED]>
To: "Thomas Kishel" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, May 13, 2003 11:23 PM
Subject: DBD::Multiplex
> On Tue, May 13, 2003 at 02:03:28PM -0400, Thomas Kishel wrote:
> > Tim,
> >
> > So far, the most recent version works well on my systems here.
>
> An update for those on [EMAIL PROTECTED] (and for the people I've
> Bcc'd who have emailed Thomas about DBD::Multiplex in the past)...
>
> I've been working on DBD::Multiplex recently and have added some
> significant functionality as well as made it a far more compatible
> (standard) DBD and more 'transparent' so applications are less aware
> of DBD::Multiplex 'getting in the way' between themselves and the
> underlying driver(s).
>
> > I am still interested in your opinion of using SQL::Parser for
> > statement parsing. Appropriate? Efficient? Or not?
>
> Efficiency is a concern, but I have a cunning plan...
>
> I'm thinking of removing mx_exit_mode and replacing it with some
> new attributes that will offer much greater flexibility...
>
> Something along these lines:
>
>
> mx_pick_handles = sub { ... }
>
> The mx_pick_handles sub decides which child handles will be used.
>
> The default mx_pick_handles sub will implement the mx_master_id
> logic, but the application can supply it's own code to use whatever
> logic it wants to pick the ordered set of handles to use.
> For example: multiple masters, smarter load balancing, routing
> queries depending on which tables are mentioned etc etc.
>
> The mx_pick_handles sub can also set the values of these attributes
> differently for each call:
>
> mx_reconnect = true | false | skip_disconnected
>
> If true, then when calling a dbh method the dbh's returned by
> mx_pick_results are ping()'d and reconnect()'d if possible before use.
> The skip_disconnected value implies true and if the reconnect fails
> then the handle is removed from the list to be used (so it won't
> generate an error). Though it is an error for no handles to be left.
>
> mx_shuffle = true | false
>
> If true, shuffles randomly the set of handles returned by mx_pick_handles.
>
> mx_errors = first | last | ignore
>
> First means stop and abort with the first error. Last means run all
> child handles but then abort with the last error encountered.
> Ignore means ignore any errors unless ALL child handles generate errors.
>
> mx_results = first | last | union
>
> First means stop after the first success. Last means return the
> last but implies that all results are remembered for later (see
> mx_pick_results below). Union is a special case I'll discuss below.
>
> mx_pick_results = sub { ... }
>
> The mx_pick_results sub decides how to interpret the results.
>
> The default mx_pick_results sub will implement the 'post-loop'
> semantics implied by the mx_errors and mx_results attributes above.
>
> mx_as_select = true | false
>
> The mx_as_select attribute turns non-select statements into select
> statement that return five fields: mx_id err errstr info, with one
> row per child handle. This is implemented already and is especially
> useful with the DBI::Shell.
>
> The mx_results = union mode mentioned above is similar but applies to
> select statements. The results of a select with mx_results = union
> is the union of all the rows returned by all the child handles.
> This is also implemented already.
>
> A final piece of magic is the ability to embed into the SQL statement
> escape sequences that get expanded differently for each child handle.
> This is especially useful with mx_results = union. For example,
>
> select '{mx id}' id, foo, bar from table where foo > bar
> or select * from table where id = '{mx id}'
> or drop table foo_{mx id}
>
> It's also possible to set handle attributes via embedded escape
> clauses:
>
> {dbi mx_as_select=1} delete from foo
>
> This's also implemented already, though I'm not set on the escape
> clause syntax.
>
> Comments?
>
> Tim.
>
> p.s. For those not on the dbi-dev mailing list who I've Bcc'd this
> to, let me know if you want to be included in any ongoing discussions.
>
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.491 / Virus Database: 290 - Release Date: 18/06/2003
