Hey Alex,
On the trac ticket, I mentioned that my motivating reason for adding
specifying default-lazy fields in the Field definition (i.e., without
having to specify them on every query set) is the implicit queries
that Django creates for foreign key lookups (e.g., item =
obj.relateditem causes
I think the sensible solution is to have what the ticket originally
suggested, a queryset/manager method to control whether a field is
lazy loading, and yes, that can be implemented without patching
django, you can, of course, make this the default by overiding the
default manager.
On Oct 14, 12:
On Tue, Oct 14, 2008 at 12:34 PM, Jesse Young <[EMAIL PROTECTED]> wrote:
> A LazyTextField that manages a dynamic model behind the scenes sounds
> like a neat idea. That would certainly make the Django side of this
> easier to manage. (But of course I have a slight bias towards code
> that exists
> And LazyTextField could create the associated model behind the scenes,
> set up a descriptor for loading its contents only when necessary,
> cache those contents so they only get queried once, etc. And all this
> without a single patch to Django's core and without you having to
> manually mainta
Moving discussion from http://code.djangoproject.com/ticket/5420.
To summarize, I patched my local version of Django by adding a boolean
'lazy' parameter to the Field constructor, e.g.
models.TextField(lazy=True), which determines whether Django loads
that field by default on select queries, and
I won't pretend to know the whole story here, but I will take issue
with some of your points. I'll leave others to people who have history
on the subject.
On Tue, Oct 14, 2008 at 3:14 AM, Jesse Young <[EMAIL PROTECTED]> wrote:
> * If you split them out, you have to manually create one model every
