> Yeah, I think it's simpler and safer to let the type be specified > explicitly. It's just impossible to tell when stored procedures are > involved. We alreay have doSelect(), doUpdate(), etc. statements, > so those methods may as well specify explicitly the type of > connection they need. For user-defined methods / custom SQL, we'll > let the users specify the connection type. Default would be master, > though, which should keep backwards compatibility.>> Hans>> David Zülke wrote:>> Hmmm... sure? AFAIK, that's just what SQLRelay, MySQLProxy et al >> do... But yeah, you might have a point.>> David>> Am 07.01.2008 um 16:56 schrieb Hans Lellelid:>>> Ok, I think I understand how this would work. One change, though, >>> is that I'd like to not have any SQL-parsing done by Propel to >>> determine which connection to use. I think the connection type >>> (master/write or slave/read) needs to be explicitly requested by >>> the generated peer classes. There's no good way to determine >>> whether a SQL statement represents a read or a write operation.>>>>>> Hans>>>>>> David Zülke wrote:>>>> No, Propel uses an instance of the router to determine which >>>> connection to write to. That is done by calling a method on the >>>> router, along with the SQL query. The router could then decide >>>> which actual connection to return. In Propels default >>>> implementation this would, unconditionally, be a random slave for >>>> any SELECT; for everything else, it would be the master connection.>>>>>>>>>>>> David>>>>>>>>>>>>>>>> Am 07.01.2008 um 15:47 schrieb Hans Lellelid:>>>>>>>>> I'm not sure I understand how they fit in to the big picture, >>>>> though. Does PropelPDO implement PropelReplicationRouter? Or >>>>> are these separate objects -- and if so, it seems like this >>>>> would be a breaking API change?>>>>>>>>>> Hans>>>>>>>>>> David Zülke wrote:>>>>>> An idea...>>>>>> interface PropelReplicationRouter { /* with some stuff */ }>>>>>>>>>>>> Such an implementation is used to determine where to write to. >>>>>> We have a default one that shoots SELECTs to a random slave, >>>>>> rest to a master. It's not a static class, so instead of >>>>>> setting a class name in the configuration, a user could also >>>>>> provide an existing instance (because, for instance, he needed >>>>>> to initialize it with whatever information first).>>>>>>>>>>>> Thoughts?>>>>>>>>>>>>>>>>>> David>>>>>>>>>>>>>>>>>>>>>>>> Am 04.01.2008 um 14:57 schrieb Hans Lellelid:>>>>>>>>>>>>> Hi All ->>>>>>>>>>>>>> I wanted to re-open this discussion. I'm currently working >>>>>>> with the>>>>>>> various PDO subclasses in Propel to address the need for >>>>>>> logging, etc.>>>>>>> As part of this, I'm also going to be refactoring the master/ >>>>>>> slave stuff>>>>>>> a bit. I wanted to provide some information about what I'm >>>>>>> currently>>>>>>> thinking of and get someone (Moritz?) to provide a unified set >>>>>>> of>>>>>>> requirements for good replication support -- with the >>>>>>> requirement that>>>>>>> it not cause excessive complexity or performance penalties to >>>>>>> those who>>>>>>> don't need the replication support. Ideally, I'd also not >>>>>>> like to have>>>>>>> the replication support affect the OM build.>>>>>>>>>>>>>> So, currently in the works is a system like this (this is >>>>>>> mostly code by>>>>>>> Christian):>>>>>>>>>>>>>> - Propel configuration parsing will look for the presence of >>>>>>> <slave>>>>>>>> connection configurations in the runtime configuration file. >>>>>>> If they>>>>>>> are present, the ReplicationPDO class will be used (instead of >>>>>>> the>>>>>>> default, PropelPDO). ReplicationPDO delegates read queries >>>>>>> (SELECT>>>>>>> statements) to a *random* slave. The slave connection is only >>>>>>> actually>>>>>>> initialized when requested. The SlavePDO class is used for >>>>>>> the slave>>>>>>> connections (when they're initialized); this class overrides >>>>>>> methods to>>>>>>> ensure that it is only performing read queries.>>>>>>> - It is also possible to override the PDO subclass by >>>>>>> specifying a>>>>>>> <classname> within the <connection> for the master connection >>>>>>> or the>>>>>>> slave connections. It is worth noting that the generated code >>>>>>> requires>>>>>>> a PropelPDO object (for nested transaction support), so the >>>>>>> custom class>>>>>>> will have to subclass PropelPDO.>>>>>>>>>>>>>> Some questions / comments I have:>>>>>>> - Is there a reason to use random connections for every SELECT >>>>>>> query?>>>>>>> Or should we iterate over slaves (if more than one)? -- Maybe>>>>>>> compromise would be to start with a random slave and then loop >>>>>>> over>>>>>>> them. I don't know that calling rand() for every SELECT >>>>>>> statement is a>>>>>>> big performance penalty, but it doesn't seem entirely necessary.>>>>>>> - Is it strictly necessary to enforce READ-only in the >>>>>>> SlavePDO? i.e.>>>>>>> if a slave object is explicitly asked to perform an update, >>>>>>> should this>>>>>>> be allowed? I guess my concern is that by checking the SQL >>>>>>> for 'SELECT'>>>>>>> (but not 'SELECT INTO'), we are not comprehensively >>>>>>> eliminating update>>>>>>> statements --- e.g. "select sp_insert_into_my_table('foo', >>>>>>> 'bar')". I>>>>>>> don't think there's any good way for the ReplicationPDO to be >>>>>>> able to>>>>>>> guess, based on the SQL, which connection should be used. For >>>>>>> that>>>>>>> reason, I like Mortiz's suggestion of having this be explicitly>>>>>>> requested as part of the getConnection() call -- i.e. the >>>>>>> doSelect()>>>>>>> methods know they can use a slave, other methods will use a >>>>>>> master.>>>>>>> When fetching your own connection, the default could be >>>>>>> master, but you>>>>>>> could also fetch a slave connection if you know that you're >>>>>>> performing a>>>>>>> SQL query. Putting this into the hands of the programmer, is >>>>>>> probably>>>>>>> wise, no?>>>>>>> - From Mortiz's description below, is it safe to assume that >>>>>>> for systems>>>>>>> that don't care about replication Propel::getConnection() >>>>>>> would always>>>>>>> be returning a master connection -- regardless of whether a >>>>>>> slave was>>>>>>> requested?>>>>>>>>>>>>>> I've created an empty wiki page to hold the finalized version >>>>>>> of this:>>>>>>> http://propel.phpdb.​org/trac/wiki/Develo​pment/ReplicationSup​port>>>>>>> I'm looking for volunteer(s) to help distill this discussion >>>>>>> into a set>>>>>>> of basic requirements and help me plan (and test) this >>>>>>> implementation.>>>>>>> I definitely like what I see below (and think I understand >>>>>>> it); I just>>>>>>> want to make sure everyone is in agreement. Also, I have not >>>>>>> used db>>>>>>> replication at all, so I look for wiser input on what >>>>>>> application>>>>>>> support for this should look like. The important thing from my>>>>>>> perspective, as mentioned earlier, is that it not introduce >>>>>>> complexity>>>>>>> or penalty for those not using replication -- and also that it >>>>>>> not break>>>>>>> the current API. I don't see anything below that would do >>>>>>> either, but>>>>>>> just wanted to make that clear.>>>>>>>>>>>>>> Thanks!>>>>>>> Hans>>>>>>>>>>>>>> Moritz Mertinkat wrote:>>>>>​>>> Yeah, you're absolutely right. CONNECTION_SELECT or >>>>>​>>> CONNECTION_READ or>>>>>​>>> something like that (think i'd prefer _READ and _WRITE for >>>>>​>>> being a bit>>>>>​>>> more unspecific ;-).>>>>>​>>>>>>>>​>>> Things to think about:>>>>>​>>>>>>>>​>>> 1) If a MASTER/WRITE connection is established first (and no >>>>>​>>> master>>>>>​>>> connection is forced), should all subsequent SLAVE/SELECT/READ>>>>>​>>> "connections" use that established connection? Or would it be >>>>>​>>> better>>>>>​>>> to establish an additional SLAVE/SELECT/READ connection?>>>>>​>>> Maybe Propel::forceSingleC​onnection(true/false​)?>>>>>​>>>>>>>>​>>> 2) Propel::forceMasterC​onnection(true/false​) should be >>>>>​>>> implemented imho.>>>>>​>>>>>>>>​>>> 3) Propel::forceConsist​entConnection(true/f​alse) would be >>>>>​>>> quite nice.>>>>>​>>>>>>>>​>>> Regards,>>>>>​>>> Moritz>>>>>​>>>>>>>>​>>> Shane Langley schrieb:>>>>>​>>>> I think CONNECTION_SLAVE is a bit confusing - since >>>>>​>>>> CONNECTION_SLAVE>>>>>​>>>> could be a connection to the master.>>>>>​>>>>>>>>>​>>>> Maybe CONNECTION_SELECT?>>>>>​>>>>>>>>>​>>>> Shane.>>>>>​>>>>>>>>>​>>>> Moritz Mertinkat wrote:>>>>>​>>>>>​ Hi,>>>>>​>>>>>​>>>>>​>>>>>​ what about Propel::getConnection(..., <TYPE>) where TYPE is>>>>>​>>>>>​ something like this: CONNECTION_MASTER, CONNECTION_SLAVE?>>>>>​>>>>>​>>>>>​>>>>>​ Within a doDelete method this would be called with >>>>>​>>>>>​ CONNECTION_MASTER>>>>>​>>>>>​ whereas in a doSelect method CONNECTION_SLAVE is used.>>>>>​>>>>>​>>>>>​>>>>>​ That way there's a maximum of two open connection (first >>>>>​>>>>>​ SLAVE and>>>>>​>>>>>​ then MASTER). If a MASTER is opened first one may use that>>>>>​>>>>>​ connection also for reading (even if CONNECTION_SLAVE is >>>>>​>>>>>​ used).>>>>>​>>>>>​ PRO: the connection is _only_ established when required.>>>>>​>>>>>​>>>>>​>>>>>​ What it does NOT fix is the problem Shane described (forced >>>>>​>>>>>​ reading>>>>>​>>>>>​ from>>>>>​>>>>>​ a MASTER). Therefore a Propel::forceMasterC​onnection(true)>>>>>​>>>>>​ method may>>>>>​>>>>>​ be implemented.>>>>>​>>>>>​>>>>>​>>>>>​ [A nice add-on feature might be>>>>>​>>>>>​Propel::forceConsist​entConnection(true).​ When a slave >>>>>​>>>>>​ connection is>>>>>​>>>>>​ required the slave's status is checked first and the >>>>>​>>>>>​ connection will>>>>>​>>>>>​ only be used if the slave is up-to-date. However I do only >>>>>​>>>>>​ know how>>>>>​>>>>>​ to do this with MySQL.]>>>>>​>>>>>​>>>>>​>>>>>​ Regards,>>>>>​>>>>>​ Moritz>>>>>​>>>>>​>>>>>​>>>>>​>>>>>​>>>>>​ Shane Langley schrieb:>>>>>​>>>>>​> "Another problem with random-slave-per-query might occur >>>>>​>>>>>​> when>>>>>​>>>>>​> you're slaves are>>>>>​>>>>>​> not 100 % synchronized (i.e. some are a few seconds behind >>>>>​>>>>>​> master).>>>>>​>>>>>​> I think a single page view should (in general) be handled >>>>>​>>>>>​> by just>>>>>​>>>>>​> one slave.">>>>>​>>>>>​>>>>>>​>>>>>​> I agree with this. The first time a connection to a slave is>>>>>​>>>>>​> required a connection should be established to one slave, >>>>>​>>>>>​> and>>>>>​>>>>>​> stored as the "select" connection.>>>>>​>>>>>​>>>>>>​>>>>>​> Subsequent selects should re-use that slave .>>>>>​>>>>>​>>>>>>​>>>>>​> "[Onother idea would be to tell Propel if you need read/ >>>>>​>>>>>​> write- or just>>>>>​>>>>>​> read-access to your database. In case you only need read- >>>>>​>>>>>​> access it's>>>>>​>>>>>​> enough to connect _one_ a random slave (no master db is >>>>>​>>>>>​> required).>>>>>​>>>>>​> Maybe both ideas together would make the perfect>>>>>​>>>>>​> master-slave-propel :-]">>>>>​>>>>>​>>>>>>​>>>>>​> The reverse works as well.>>>>>​>>>>>​>>>>>>​>>>>>​> For an application I worked on I created a >>>>>​>>>>>​> ConnectionMananger class>>>>>​>>>>>​> that>>>>>​>>>>>​> handled the split between master/slave.>>>>>​>>>>>​>>>>>>​>>>>>​> I added a method "forceMaster()" that would ensure every >>>>>​>>>>>​> query>>>>>​>>>>>​> would hit the master.>>>>>​>>>>>​>>>>>>​>>>>>​> Some pages you want to have the most update-to-date data >>>>>​>>>>>​> (when>>>>>​>>>>>​> editing for example) loaded into>>>>>​>>>>>​> your form. Without this method, the data would come from a >>>>>​>>>>>​> slave>>>>>​>>>>>​> (since the select query is not in a transaction) which >>>>>​>>>>>​> could be>>>>>​>>>>>​> out-of-date by a few seconds.>>>>>​>>>>>​>>>>>>​>>>>>​> In this case, you don't need a slave connection at all.>>>>>​>>>>>​>>>>>>​>>>>>​> Regards,>>>>>​>>>>>​>>>>>>​>>>>>​> Shane.>>>>>​>>>>>​>>>>>>​>>>>>​> Moritz Mertinkat wrote:>>>>>​>>>>>​>> Hi everybody,>>>>>​>>>>>​>>>>>>>​>>>>>​>> I've just looked at the code and I think it's a great >>>>>​>>>>>​>> thing to add>>>>>​>>>>>​>> to propel.>>>>>​>>>>>​>>>>>>>​>>>>>​>> What I think should be improved is that all slave >>>>>​>>>>>​>> connections get>>>>>​>>>>>​>> connected at>>>>>​>>>>>​>> the moment Propel ist loaded. That is, if you have eight >>>>>​>>>>>​>> MySQL>>>>>​>>>>>​>> slave servers>>>>>​>>>>>​>> you establish a MySQL connection to all of them, even >>>>>​>>>>>​>> though you>>>>>​>>>>>​>> just need one>>>>>​>>>>>​>> (for example). Kinda slow :)>>>>>​>>>>>​>>>>>>>​>>>>>​>> Wouldn't it be better to load just _one_ random slave >>>>>​>>>>>​>> upon starting?>>>>>​>>>>>​>>>>>>>​>>>>>​>> Another problem with random-slave-per-query might occur >>>>>​>>>>>​>> when>>>>>​>>>>>​>> you're slaves are>>>>>​>>>>>​>> not 100 % synchronized (i.e. some are a few seconds >>>>>​>>>>>​>> behind master).>>>>>​>>>>>​>> I think a single page view should (in general) be handled >>>>>​>>>>>​>> by just>>>>>​>>>>>​>> one slave.>>>>>​>>>>>​>>>>>>>​>>>>>​>> For those who (really) want to have a different slave >>>>>​>>>>>​>> each query>>>>>​>>>>>​>> one might add>>>>>​>>>>>​>> a flag to Propel::init or to the configuration.>>>>>​>>>>>​>>>>>>>​>>>>>​>> [Onother idea would be to tell Propel if you need read/ >>>>>​>>>>>​>> write- or just>>>>>​>>>>>​>> read-access to your database. In case you only need read- >>>>>​>>>>>​>> access it's>>>>>​>>>>>​>> enough to connect _one_ a random slave (no master db is >>>>>​>>>>>​>> required).>>>>>​>>>>>​>> Maybe both ideas together would make the perfect>>>>>​>>>>>​>> master-slave-propel :-]>>>>>​>>>>>​>>>>>>>​>>>>>​>> Regards,>>>>>​>>>>>​>> Moritz>>>>>​>>>>>​>>>>>>>​>>>>>​>>>>>>>​>>>>>​>> Christian Abegg schrieb:>>>>>​>>>>>​>>>>>>>​>>>>>​>>> Hi Hans>>>>>​>>>>>​>>>>>>>>​>>>>>​>>> - This will work fine without master/slave replication >>>>>​>>>>>​>>> and it>>>>>​>>>>>​>>> should not>>>>>​>>>>>​>>> have any impact on a existing single db setup. Although >>>>>​>>>>>​>>> I'd be>>>>>​>>>>>​>>> glad for>>>>>​>>>>>​>>> further testings or code reviews.>>>>>​>>>>>​>>>>>>>>​>>>>>​>>> - The changes in the Propel class primarly touch the>>>>>​>>>>>​>>> "getConnection" method.>>>>>​>>>>>​>>> I copied some code from it to that new "initConnection" >>>>>​>>>>>​>>> method>>>>>​>>>>>​>>> which can now>>>>>​>>>>>​>>> be called multiple times from the "getConnection" method >>>>>​>>>>>​>>> (i.e.>>>>>​>>>>>​>>> for the>>>>>​>>>>>​>>> master and its slaves).>>>>>​>>>>>​>>>>>>>>​>>>>>​>>> - Of course I'll document it.>>>>>​>>>>>​>>>>>>>>​>>>>>​>>> Please note that I've just tried it on a mysql >>>>>​>>>>>​>>> replication setup.>>>>>​>>>>>​>>> I'd be>>>>>​>>>>>​>>> happy to run some tests. Do you have a test suite?>>>>>​>>>>>​>>>>>>>>​>>>>>​>>> Regards,>>>>>​>>>>>​>>> Christian>>>>>​>>>>>​>>>>>>>>​>>>>>​>>>>>>>>​>>>>>​>>>>>>>>​>>>>>​>>>>>>>>​>>>>>​>>>>>>>>​>>>>>​>>>>>>>>​>>>>>​>>>>>>>>​>>>>>​>>> Hans Lellelid wrote:>>>>>​>>>>>​>>>>>>>>​>>>>>​>>>> Hi Christian,>>>>>​>>>>>​>>>>>>>>>​>>>>>​>>>> Yes :)>>>>>​>>>>>​>>>>>>>>>​>>>>>​>>>> Am I right in assuming that this will work fine without a>>>>>​>>>>>​>>>> master/slave>>>>>​>>>>>​>>>> setup? (i.e. in traditional, single-db model?)>>>>>​>>>>>​>>>>>>>>>​>>>>>​>>>> I didn't drop these in to do a diff, but the PropelPDO >>>>>​>>>>>​>>>> looked>>>>>​>>>>>​>>>> fairly>>>>>​>>>>>​>>>> similar; Propel class too?>>>>>​>>>>>​>>>>>>>>>​>>>>>​>>>> I'd like to get this added in, though. I think it >>>>>​>>>>>​>>>> would be a great>>>>>​>>>>>​>>>> benefit.>>>>>​>>>>>​>>>>>>>>>​>>>>>​>>>> Would you be willing to contribute some documentation >>>>>​>>>>>​>>>> on getting>>>>>​>>>>>​>>>> this>>>>>​>>>>>​>>>> setup? -- e.g. in 1.3 user guide?>>>>>​>>>>>​>>>>>>>>>​>>>>>​>>>> Thanks,>>>>>​>>>>>​>>>> Hans>>>>>​>>>>>​>>>>>>>>>​>>>>>​>>>>>>>>>​>>>>>​>>>> Christian Abegg wrote:>>>>>​>>>>>​>>>>>>>>>​>>>>>​>>>>>​ hi there>>>>>​>>>>>​>>>>>​>>>>>​>>>>>​>>>>>​ here's a refinend implementation of r/w splitting:>>>>>​>>>>>​>>>>>​http://www.nabble.co​m/file/p14116000/rwS​plitting.zip>>>>>​>>>>>​>>>>>​ rwSplitting.zip>>>>>​>>>>>​>>>>>​>>>>>​>>>>>​>>>>>​ anyone interested?>>>>>​>>>>>​>>>>>​>>>>>​>>>>>​>>>>>​ regards>>>>>​>>>>>​>>>>>​ christian>>>>>​>>>>>​>>>>>​>>>>>​>>>>>​>>>>>​>>>>>​>>>>>​>>>>>​>>>>>​>>>>>​>>>>>​ Christian Abegg wrote:>>>>>​>>>>>​>>>>>​>>>>>​>>>>>​>>>>>​> hi cameron, dear devs>>>>>​>>>>>​>>>>>​>>>>>>​>>>>>​>>>>>​> thank you for your reply. i made a first try to >>>>>​>>>>>​>>>>>​> implement it>>>>>​>>>>>​>>>>>​> the way you>>>>>​>>>>>​>>>>>​> proposed:>>>>>​>>>>>​>>>>>​> - the propel class initializes a PropelPDO object >>>>>​>>>>>​>>>>>​> which acts>>>>>​>>>>>​>>>>>​> as db>>>>>​>>>>>​>>>>>​> connection to the master server>>>>>​>>>>>​>>>>>​> - the PropelPDO object also holds an array of other PDO>>>>>​>>>>>​>>>>>​> connections used>>>>>​>>>>>​>>>>>​> for read only queries>>>>>​>>>>>​>>>>>​>>>>>>​>>>>>​>>>>>​> pro: realtively simple to implement, building up on the>>>>>​>>>>>​>>>>>​> existing code>>>>>​>>>>>​>>>>>​> contra: PropelPDO extending PDO is no more used as a >>>>>​>>>>>​>>>>>​> singe db>>>>>​>>>>>​>>>>>​> connection>>>>>​>>>>>​>>>>>​>>>>>>​>>>>>​>>>>>​> have a look at the two patches attached. they are a >>>>>​>>>>>​>>>>>​> very first>>>>>​>>>>>​>>>>>​> draft>>>>>​>>>>>​>>>>>​> showing the way I would choose.>>>>>​>>>>>​>>>>>​>http://www.nabble.co​m/file/p13820966/Pro​pel.diff>>>>>​>>>>>​>>>>>​> Propel.diff>>>>>​>>>>>​>>>>>​>http://www.nabble.co​m/file/p13820966/Pro​pelPDO.diff>>>>>​>>>>>​>>>>>​> PropelPDO.diff>>>>>​>>>>>​>>>>>​>>>>>>​>>>>>​>>>>>​> please let me know if you'd appreciate any further >>>>>​>>>>>​>>>>>​> work on>>>>>​>>>>>​>>>>>​> that matter>>>>>​>>>>>​>>>>>​> and>>>>>​>>>>>​>>>>>​> if there are architectural changes/constraints to be >>>>>​>>>>>​>>>>>​> considered.>>>>>​>>>>>​>>>>>​>>>>>>​>>>>>​>>>>>​> cheers>>>>>​>>>>>​>>>>>​> christian>>>>>​>>>>>​>>>>>​>>>>>>​>>>>>​>>>>>​>>>>>>​>>>>>​>>>>>​> Cameron Brunner wrote:>>>>>​>>>>>​>>>>>​>>>>>>​>>>>>​>>>>>​>> There is no reason this cant be done purely by >>>>>​>>>>>​>>>>>​>> slotting in a new>>>>>​>>>>>​>>>>>​>> PropelPDO layer with intelligence on what to send >>>>>​>>>>>​>>>>>​>> the query>>>>>​>>>>>​>>>>>​>> to IMO. I>>>>>​>>>>>​>>>>>​>> have thought this out before and it shouldn't be too >>>>>​>>>>>​>>>>>​>> painful>>>>>​>>>>>​>>>>>​>> depending>>>>>​>>>>>​>>>>>​>> upon just how smart you want it.>>>>>​>>>>>​>>>>>​>>>>>>>​>>>>>​>>>>>​>> On 11/3/07, Christian Abegg <abegg dot ch at gmail dot com> >>>>>​>>>>>​>>>>>​>> wrote:>>>>>​>>>>>​>>>>>​>>>>>>>​>>>>>​>>>>>​>>> hi>>>>>​>>>>>​>>>>>​>>>>>>>>​>>>>>​>>>>>​>>> i'd like to use my propel app in an environment >>>>>​>>>>>​>>>>>​>>> where the>>>>>​>>>>>​>>>>>​>>> db-master is>>>>>​>>>>>​>>>>>​>>> replicated to one or more slave databases. the >>>>>​>>>>>​>>>>>​>>> master gets>>>>>​>>>>>​>>>>>​>>> the writing>>>>>​>>>>>​>>>>>​>>> statements, the slave gets the reading statements.>>>>>​>>>>>​>>>>>​>>>>>>>>​>>>>>​>>>>>​>>> in my opinion, the propel layer would be appropriate>>>>>​>>>>>​>>>>>​>>> implement that>>>>>​>>>>>​>>>>>​>>> function.>>>>>​>>>>>​>>>>>​>>>>>>>>​>>>>>​>>>>>​>>> as far as i see, there is no such feature in propel.>>>>>​>>>>>​>>>>>​>>>>>>>>​>>>>>​>>>>>​>>> after a short look into the generated base-classes, >>>>>​>>>>>​>>>>>​>>> it seems>>>>>​>>>>>​>>>>>​>>> like a>>>>>​>>>>>​>>>>>​>>> quite an easy task to implement a read-write >>>>>​>>>>>​>>>>>​>>> splitting.>>>>>​>>>>>​>>>>>​>>> assuming that>>>>>​>>>>>​>>>>>​>>> all reading queries call the "doSelectStmt" >>>>>​>>>>>​>>>>>​>>> function, i'd>>>>>​>>>>>​>>>>>​>>> introduce>>>>>​>>>>>​>>>>>​>>> the>>>>>​>>>>>​>>>>>​>>> DATABASE_NAME_READ-constant which points to the>>>>>​>>>>>​>>>>>​>>> configuration of the>>>>>​>>>>>​>>>>>​>>> slave-db.>>>>>​>>>>>​>>>>>​>>>>>>>>​>>>>>​>>>>>​>>> for load balancing between multiple slave-db's i'd >>>>>​>>>>>​>>>>>​>>> use the>>>>>​>>>>>​>>>>>​>>> mysql-proxy.>>>>>​>>>>>​>>>>>​>>> but a simple round robin mechanism could be >>>>>​>>>>>​>>>>>​>>> implemented in>>>>>​>>>>>​>>>>>​>>> propel as>>>>>​>>>>>​>>>>>​>>> well.>>>>>​>>>>>​>>>>>​>>>>>>>>​>>>>>​>>>>>​>>> i'm not sure wheter this approach could solve my >>>>>​>>>>>​>>>>>​>>> problem. a big>>>>>​>>>>>​>>>>>​>>> question>>>>>​>>>>>​>>>>>​>>> is: are the connection objects cached by propel? or >>>>>​>>>>>​>>>>>​>>> is the>>>>>​>>>>>​>>>>>​>>> $con-variable>>>>>​>>>>>​>>>>>​>>> always null if the user doesn't give a connection >>>>>​>>>>>​>>>>>​>>> on the>>>>>​>>>>>​>>>>>​>>> application>>>>>​>>>>>​>>>>>​>>> layer?>>>>>​>>>>>​>>>>>​>>>>>>>>​>>>>>​>>>>>​>>> if that enhancement is considered usefull and could >>>>>​>>>>>​>>>>>​>>> be>>>>>​>>>>>​>>>>>​>>> implemented>>>>>​>>>>>​>>>>>​>>> within reasonable time, i'd be glad to help.>>>>>​>>>>>​>>>>>​>>>>>>>>​>>>>>​>>>>>​>>> christian abegg>>>>>​>>>>>​>>>>>​>>>>>>>>​>>>>>​>>>>>​>>>>>>>>​>>>>>​>>>>>​>>> ps: my attempts to add an enhancement ticket failed >>>>>​>>>>>​>>>>>​>>> beacaus>>>>>​>>>>>​>>>>>​>>> they were>>>>>​>>>>>​>>>>>​>>> rejected as spam by trac.>>>>>​>>>>>​>>>>>​>>>>>>>>​>>>>>​>>>>>​>>>--------------------​--------------------​--------------------​--------->>>>>​>>>>>​>>>>>​>>>>>>>>​>>>>>​>>>>>​>>> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org>>>>>​>>>>>​>>>>>​>>> For additional commands, e-mail: dev-help at propel dot tigris dot org>>>>>​>>>>>​>>>>>​>>>>>>>>​>>>>>​>>>>>​>>>>>>>>​>>>>>​>>>>>​>>>>>>>>​>>>>>​>>>>>​>> -- >>>>>​>>>>>​>>>>>​>> Cameron Brunner>>>>>​>>>>>​>>>>>​>>>>>>>​>>>>>​>>>>>​>> Want a better web browser?>>>>>​>>>>>​>>>>>​>>http://www.spreadfir​efox.com/?q=affiliat​es&id=182780​&t=1>>>>>​>>>>>​>>>>>​>>>>>>>​>>>>>​>>>>>​>>--------------------​--------------------​--------------------​--------->>>>>​>>>>>​>>>>>​>>>>>>>​>>>>>​>>>>>​>> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org>>>>>​>>>>>​>>>>>​>> For additional commands, e-mail: dev-help at propel dot tigris dot org>>>>>​>>>>>​>>>>>​>>>>>>>​>>>>>​>>>>>​>>>>>>>​>>>>>​>>>>>​>>>>>>>​>>>>>​>>>>>​>>>>>>>​>>>>>​>>>>--------------------​--------------------​--------------------​--------->>>>>​>>>>>​>>>>>>>>>​>>>>>​>>>> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org>>>>>​>>>>>​>>>> For additional commands, e-mail: dev-help at propel dot tigris dot org>>>>>​>>>>>​>>>>>>>>>​>>>>>​>>>>>>>>>​>>>>>​>>>>>>>>>​>>>>>​>>>>>>>>>​>>>>>​>>> -- >>>>>​>>>>>​>>> View this message in context:>>>>>​>>>>>​>>>http://www.nabble.co​m/r-w-splitting-in-m​aster-slave-db-repli​cation-environment-t​f4740128.html#a14124​959>>>>>​>>>>>​>>>>>>>>​>>>>>​>>> Sent from the propel - dev mailing list archive at >>>>>​>>>>>​>>> Nabble.com.>>>>>​>>>>>​>>>>>>>>​>>>>>​>>>>>>>>​>>>>>​>>>>>>>>​>>>>>​>>>>>>>​>>>>>​>>--------------------​--------------------​--------------------​--------->>>>>​>>>>>​>> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org>>>>>​>>>>>​>> For additional commands, e-mail: dev-help at propel dot tigris dot org>>>>>​>>>>>​>>>>>>>​>>>>>​>>>>>>>​>>>>>​>>>>>>>​>>>>>​>>>>>>​>>>>>​>--------------------​--------------------​--------------------​--------->>>>>​>>>>>​> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org>>>>>​>>>>>​> For additional commands, e-mail: dev-help at propel dot tigris dot org>>>>>​>>>>>​>>>>>>​>>>>>​>>>>>​>>>>>​--------------------​--------------------​--------------------​--------->>>>>​>>>>>​ To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org>>>>>​>>>>>​ For additional commands, e-mail: dev-help at propel dot tigris dot org>>>>>​>>>>>​>>>>>​>>>>>​>>>>>​>>>>>>>>>​>>>>--------------------​--------------------​--------------------​--------->>>>>​>>>> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org>>>>>​>>>> For additional commands, e-mail: dev-help at propel dot tigris dot org>>>>>​>>>>>>>>>​>>>>>>>>​>>>--------------------​--------------------​--------------------​--------->>>>>​>>> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org>>>>>​>>> For additional commands, e-mail: dev-help at propel dot tigris dot org>>>>>​>>>>>>>>>>>>>>>>> --------------------​--------------------​--------------------​--------->>>>>>> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org>>>>>>> For additional commands, e-mail: dev-help at propel dot tigris dot org>>>>>>>>>>>>>>>>>>>>>>>>>> --------------------​--------------------​--------------------​--------->>>>>> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org>>>>>> For additional commands, e-mail: dev-help at propel dot tigris dot org>>>>>>>>>>>>>>>> --------------------​--------------------​--------------------​--------->>>>> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org>>>>> For additional commands, e-mail: dev-help at propel dot tigris dot org>>>>>>>>>>>>>>>>>> --------------------​--------------------​--------------------​--------->>>> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org>>>> For additional commands, e-mail: dev-help at propel dot tigris dot org>>>>>>>>>> --------------------​--------------------​--------------------​--------->>> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org>>> For additional commands, e-mail: dev-help at propel dot tigris dot org>>>>>>>> --------------------​--------------------​--------------------​--------->> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org>> For additional commands, e-mail: dev-help at propel dot tigris dot org>> --------------------​--------------------​--------------------​---------> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org> For additional commands, e-mail: dev-help at propel dot tigris dot org>>