On Thu, 2007-11-01 at 08:53 -0400, George Vilches wrote:
> (Off-list because this mostly doesn't apply to non qs-rf people)
>
> Thank you for the clarification on OneToOneFields and required
> relationships. We've been working with a very high volume legacy
> database that we're importing the data into, and that data's not exactly
> pristine. We're used to related tables solving the problems with
> non-correlated data, it sounds like we're just going to be forced to
> clean it up, and that's fine. Django's ORM provides a different way of
> approaching the problem, and we just have to be willing to take full
> advantage of that mechanism and not the previous SQL "trickery" that's
> been used. :)
>
> As always, your involvement in these questions is appreciated.
> Sometimes what we expect intuitively is a bug just isn't because we're
> taking advantage of a "non-feature" of the system.
>
> ---
>
> I had one other question in there directed to you, regarding
> OneToOneFields. In the new qs-rf, is it *possible* to make these
> relationships bidirectional for the purposes of caching data?
Probably best to ask these questions on django-developers in future, so
that we can get a few opinions.
It might be possible when I fix up #5020. There's probably no good
reason that won't work for reverse relations. By default
select_related() won't follow reverse relations ... there are just too
many possibilities and, by and large, it would be very inefficient,
since you generally don't care about them (in the 90% case). However,
with the features of #5020 in place, you could probably specify the
reverse relations you wanted to follow and have it work. After all, User
has an implicit field called "member_set", or something like that, in
your example, so qs.select_related('member_set') might work -- not quite
sure what the reverse for a OneToOneField looks like, because I've never
used it -- I tend to stick to ForeignKey(unique=True) for a lot of those
types of things, but that's mostly an implementation detail.
I haven't finished integrating David Cramer's work there. His idea is
quite a good one, but I have to port the whole implementation across.
I've started doing it in it a branch locally, but it's still work in
progress. So I don't know if this really will work easily in practice,
but it's not beyond the realms of possibility.
> If they're not going to be currently but it is something the ORM is
> capable of, it would be something I would work on as well as the Bit
> class. Here's our deal:
>
> class User(models.Model): pass
>
> class Member(models.Model):
> models.OneToOneField(User)
> class MemberAvatar(models.Model):
> models.OneToOneField(User)
> class MemberBadges(models.Model):
> models.OneToOneField(User)
> ...
>
> We have 10+ of these types of tables. The data makes sense to be
> separated because there's a lot of large data blocks in some of these
> columns, and we have *very large* amounts of data (100GB range on one
> implementation of this system), so having it all in one table is
> inappropriate.
>
> For reporting purposes though, we would like to be able to
> .select_related() on User, and get a cached copy of each of the OneToOne
> relationships. It seems reasonable by the very essence of OneToOne, but
> I don't know if there's some limitation that would prevent that
> following from happening. However, when we pull 50 users, having 50*N
> tables of extra queries when we need data from a few separate places
> makes the whole task unappealing to use the Django ORM for.
Well, I'd be rearranging my access so that it's only N extra queries:
collect all the User objects first and then add a
filter(user_id__in=[...]). But I understand your point.
For some things, though, Django's ORM isn't going to be ideal. We aren't
trying to be SQLAlchemy. That's intentional.
Something that's been requested in the past and might be worth fleshing
out in the future (probably after queryset-refactor, though) is how to
take a result set from custom SQL and easily convert that back into a
collection of models. So that people can write their own custom SQL but
get back models in a QuerySet sort of format. Not exactly a QuerySet,
since adding extra filters probably won't work easily, but it's
interesting to play with. That's possibly even post-1.0 work, but it's
also not something that necessarily has to sit in core after the
queryset refactor lands, so I'm hoping there's some exploration that
happens there in a few months.
Regards,
Malcolm
--
Why be difficult when, with a little bit of effort, you could be
impossible.
http://www.pointy-stick.com/blog/
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
