<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: How to use multiple databases in TurboGears 2.0</title>
	<atom:link href="http://blog.curiasolutions.com/2009/07/multiple-databases-in-turbogears-2/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.curiasolutions.com/2009/07/multiple-databases-in-turbogears-2/</link>
	<description>Technology thoughts and ideas</description>
	<lastBuildDate>Tue, 13 Jul 2010 02:50:28 -0700</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.6</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Ants Aasma</title>
		<link>http://blog.curiasolutions.com/2009/07/multiple-databases-in-turbogears-2/comment-page-1/#comment-43</link>
		<dc:creator>Ants Aasma</dc:creator>
		<pubDate>Mon, 19 Oct 2009 16:43:42 +0000</pubDate>
		<guid isPermaLink="false">http://blog.curiasolutions.com/?p=87#comment-43</guid>
		<description>You don&#039;t necessarily need separate sessions for the different databases. If the session isn&#039;t explicitly bound to an engine it will try to find the engine via the mapper, by looking at bind of the metadata of the mapped table. By default declarative_base() will create its own metadata. This means that just binding the two metadatas to the engines and leaving the session unbound will do what you want, objects and queries will get routed to the correct database and connections acquired on each database as needed. Lazy loading of relations will also work across databases, but joins won&#039;t - each query needs to go to one database. It will even manage coordinating two-phase transactions across the two databases for you if you manage the after crash cleanup of prepared-but-not-commited transactions on your own. Only gotcha might be that you&#039;ll need to provide a mapper or a class to use for engine resolution if you execute plain-text SQL.</description>
		<content:encoded><![CDATA[<p>You don&#8217;t necessarily need separate sessions for the different databases. If the session isn&#8217;t explicitly bound to an engine it will try to find the engine via the mapper, by looking at bind of the metadata of the mapped table. By default declarative_base() will create its own metadata. This means that just binding the two metadatas to the engines and leaving the session unbound will do what you want, objects and queries will get routed to the correct database and connections acquired on each database as needed. Lazy loading of relations will also work across databases, but joins won&#8217;t &#8211; each query needs to go to one database. It will even manage coordinating two-phase transactions across the two databases for you if you manage the after crash cleanup of prepared-but-not-commited transactions on your own. Only gotcha might be that you&#8217;ll need to provide a mapper or a class to use for engine resolution if you execute plain-text SQL.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
