Hi all, So yeah, we could restore the option and put creation of a slave engine instance to EngineFacade class, but I don't think we want this.
The only reason why slave connections aren't implemented e.g. in SQLAlchemy is that, SQLAlchemy, as a library can't decide for you how those engines should be used: do you have an ACTIVE-ACTIVE setup or ACTIVE-PASSIVE, to which database reads/writes must go, and so on. The same is true for oslo.db. Nova is the only project that uses slave_connection option and it was kind of broken: nova bare metal driver uses a separate database and there was no way to use a slave db connection for it. So due to lack of consistency in using of slave connection, IMO, this should be left up to application to decide, how to use it. And we provide EngineFacade helper already. So I'd just say, create an EngineFacade instance for a slave connection explicitly, if you want it to be used like it is used in Nova right now. Thanks, Roman On Wed, Mar 5, 2014 at 8:35 AM, Doug Hellmann <doug.hellm...@dreamhost.com> wrote: > > > > On Wed, Mar 5, 2014 at 10:43 AM, Alexei Kornienko > <alexei.kornie...@gmail.com> wrote: >> >> Hello Darren, >> >> This option is removed since oslo.db will no longer manage engine objects >> on it's own. Since it will not store engines it cannot handle query >> dispatching. >> >> Every project that wan't to use slave_connection will have to implement >> this logic (creation of the slave engine and query dispatching) on it's own. > > > If we are going to have multiple projects using that feature, we will have > to restore it to oslo.db. Just because the primary API won't manage global > objects doesn't mean we can't have a secondary API that does. > > Doug > > >> >> >> Regards, >> >> >> On 03/05/2014 05:18 PM, Darren Birkett wrote: >> >> Hi, >> >> I'm wondering why in this commit: >> >> >> https://github.com/openstack/oslo-incubator/commit/630d3959b9d001ca18bd2ed1cf757f2eb44a336f >> >> ...the slave_connection option was removed. It seems like a useful option >> to have, even if a lot of projects weren't yet using it. >> >> Darren >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
