On Fri, Aug 20, 2010 at 6:48 AM, Andy <selforgani...@gmail.com> wrote:
>
>
> On Aug 19, 9:28 am, Russell Keith-Magee <russ...@keith-magee.com>
> wrote:
>
>
>> You've got the right idea, but the implementation you provide probably
>> won't be comprehensive enough in practice. The hint is any extra
>> information that will help you determine the right database to use;
>> there's no guarantee that the instance hint will exist, or if it does,
>> that it will be an instance of Tweet. For example, when you create a
>> tweet, you won't have an instance -- and even if you did, you won't
>> have an author_id -- but you still need to nominate a write database
>> in order to save the instance.
>
> I'm not sure I understand:
>
> I thought hints will always contain the instance that is to be read or
> written. You're saying that's not the case? Under what circumstances
> will hints *not* contain the instance?
>
> In your example, I'd only want to write to the database when I'm ready
> to save a tweet. By that time a tweet instance would be in existence
> and that it would have an author_id, correct? So I don't understand
> your example. Did I miss something? Please elaborate.
The instance will exist, but the author_id won't. Unless you are
manually allocating the primary key, the primary key is allocated by
the database at the time of object save, which means you won't be able
to determine the primary key until *after* the object is saved (which
is obviously too late to determine the database allocation).
As for the instance not existing: Consider the following queries:
MyModel.objects.filter(foo=bar)
or
MyModel.objects.update(foo=bar)
These are read and write queries respectively, but neither has any
meaningful concept of a current "instance".
When foreign keys are involved, the 'instance' gets a little more
complicated. Consider the case of an Book model that contains a
foreign key to Author, and you're assigning an author (value) to an
instance of Book (instance). Here's the snippet of code that gets
executed to determine the database that is used:
if instance._state.db is None:
instance._state.db =
router.db_for_write(instance.__class__, instance=value)
elif value._state.db is None:
value._state.db = router.db_for_write(value.__class__,
instance=instance)
That is, if your instance or value isn't current assigned to a
database, the instance hint will be the 'other' object in the
relation.
Lastly, I would point out that the multi-db features of Django are
very new. While every effort has been made to provide an interface
that is rich enough to implement a wide range of routing schemes, I'm
also sure that there is lots of room for improvement. The "hints"
structure has been left intentionally opaque specifically to allow for
this kind of improvement. If you think that Django isn't providing
sufficient information to implement a specific routing scheme, make
your case and we will see about adding whatever extra information may
be required.
Yours,
Russ Magee %-)
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
