Jacob Kaplan-Moss wrote:
> I can buy that... but it doesn't just return useless data, it returns
> a potentially HUGE dataset -- every single EventTime in the system!
> -- which an unwary template author might stumble across and bring the
> site to its knees.
Surely a template author couldn't do
On 3/24/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
I'm really asking about something more abstract, though -- is there(should there be) the ability to define manager methods availableonly in a related context?+1 to this idea. The managers used by object descriptors already have this problem,
On Mar 23, 2006, at 5:36 PM, Adrian Holovaty wrote:
> Is it a big deal that Place.objects.all_event_times() exists and
> returns useless data? If you don't need to use the method in a certain
> context, don't use it. :)
I can buy that... but it doesn't just return useless data, it returns
a pot
On 3/23/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> What I've been doing is replacing the ``get_event_times`` method with
> a manager method on Event, so you could do something like::
>
> place_object.event_set.all_event_times()
>
> I *really* like this idiom; it feels very natural.
wouldn't it be better to use the contribute to class method and add
the method onto the place object at startup?
On 3/24/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
>
> Howdy folks --
>
> Feels kinda weird to ask a question on this list, but I'm a little
> stumped.
>
> I'm working on conver
Howdy folks --
Feels kinda weird to ask a question on this list, but I'm a little
stumped.
I'm working on converting Ellington into the magic-removal-style
syntax, and I've been running into an interesting situation with
"optional" relationships. An example might illustrate this best::
