On May 11, 2014, at 4:28 PM, Joseph Casale <[email protected]> wrote:
> Hey Michael, > > I really appreciate all that, it was extremely informative. For the academic > sake I have this > extrapolated to include all the actual intermediate tables that TableB would > include. > > For the academic sake, without the mixin and proxy, given a traditional > approach where TableA > is already populated, what is the simplest customary approach usually > leveraged for feeding > data into the TableB objects relationship columns? Is there a shorter > mechanism than an actual > query statement? Let's say, if you have TableA with 1->foo, 2->bar. That data is only in the database. Then you want TableB.name = "foo" to result in TableB.name_id = 1. Where else would the "1" come from, except ultimately via a query at some point? The options are: 1. hardcode 1->foo, 2->bar into the application. Sort of makes TableA pointless. For fixed sets of application values, I recommend using enums instead, see http://techspot.zzzeek.org/2011/01/14/the-enum-recipe/ for when to use. 2. SELECT "TableA" up front somewhere and cache it. Then put some kind of @property on TableB.name to do a cache lookup. This is just a little awkward because if TableA changes, you have to deal with cache invalidation. 3. SELECT "TableA" on a more specific basis, possibly use caching. That's what unique object is getting you right now, it has caching. The invalidation problem is here as well though the caching is local to a specific Session; approach #2 could possibly use this also by selecting all of TableA up front per-session. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
