Diana Clarke wrote:
> Again, this investigative test is loosely based on SQLAlchemy's
> sharding test: sqlalchemy/test/orm/sharding/test_shard.py
>
>     def test_update(self):
>         print "\n"
>         session = create_session()
>         query = session.query(WeatherLocation)
>
>         # query_chooser returns: ['asia']
>         print "get tokyo:"
>         tokyo =
> query.filter_by(city='Tokyo').filter_by(continent='Asia').first()
>
>         # no new SQL
>         print "access tokyo:"
>         assert tokyo.city == "Tokyo"
>
>         # no new SQL
>         print "change tokyo:"
>         tokyo.city = "Tokyo_city_name_changed"
>
>         # uses shard_chooser by instance
>         print "save tokyo:"
>         session.add(tokyo)
>         session.commit()
>
>         # query_chooser returns: ['north_america', 'asia', 'europe',
> 'south_america']
>         print "access tokyo 2:"
>         assert tokyo.city == "Tokyo_city_name_changed"
>
> My question #2: If we already have an instance of tokyo from the 'save
> tokyo' code snippet, why is a new query_cls being instantiated to
> refresh the tokyo object in 'access tokyo 2' (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? Is there some way I
> can optimize this case, perhaps by setting the shard_id somewhere, so
> that 4 queries aren't executed in this case?

well there's two things, one left over from previous.  one is that
commit() expires all attributes in the session.  that is why new SQL is
emitted.   check the docs for rationale there.

but also, the loading of deferred attributes as earlier and expired
attributes here does have the primary key, so its a bug that shard_chooser
is being run here, since the internal function doing that is calling
query._get(), whereas ShardedQuery is being simple and only overriding
get().  You might want to change ShardedQuery to override _get() instead
(which leads me further towards pulling the trigger of moving shard.py out
to examples altogether for 06, since it really is not supportable as a
core element, just FYI).

Its also possibly worth it to get your ShardChooser to the point where it
can recognize what is effectively a get() based on filtering criterion.  
You can do this by imitating the approach in the example FindContinent
chooser in examples/sharding/attribute_shard.py.

>
> Thanks,
>
> --diana
>
> On Mon, Jan 11, 2010 at 3:38 PM, Diana Clarke
> <diana.joan.cla...@gmail.com> wrote:
>> Question #2 similar, but w/ session.add(). I'll send a new email for
>> Question #2.
> --
> 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.
>
>
>

-- 
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.


Reply via email to