diana wrote: > Hello again, > > I'm getting errors in a certain case which lead me to suspect that I'm > missing some big picture sharding concept, so to better understand > sharding I'm playing with the SQLAlchemy sharding unit tests > (sqlalchemy/test/orm/sharding/test_shard.py). > > Here's one of the investigative tests I've added in order to better > understand query_chooser: > > def test_read(self): > session = create_session() > query = session.query(WeatherLocation) > > print "get tokyo:" > # query_chooser returns: ['asia'] > tokyo = query.filter_by(city='Tokyo').filter_by > (continent='Asia').first() > > print "access tokyo:" > # query_chooser returns: ['north_america', 'asia', 'europe', > 'south_america'] > assert tokyo.city == "Tokyo" > > My question: If we already have an instance of tokyo from the 'get > tokyo' code snippet, why is a new query_cls being instantiated to > rerfesh the tokyo object on access (thus having to traverse all 4 > shards) rather than using shard_chooser and the got instance to > compute the shard based on its continent value?
You just got a new tokyo from the DB, and I assume no inherited tables are in effect, the session is brand new, so no SQL should be emitted when accessing tokyo.city, which I am assuming is a textual field. The key "city" should be present in tokyo.__dict__, and no Session should be accessed. Nothing I can see from the above code indicates a second SQL should be emitted. of course the details of the mapping might say something totally different (i.e. deferred(), joined table inhertance, etc.)
-- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
