CopiedField sounds a bit off, but otherwise I like the proposed additions.
On Thu, Sep 25, 2008 at 8:08 AM, Andrew Godwin <[EMAIL PROTECTED]>wrote:
>
> David Cramer wrote:
> > I would say ignore triggers on the DB level, until they've been
> > written in the framework.
> >
>
> Yes, this was essentially my point earlier; triggers would be nice to
> have from a consistency point of view, but it will be easier and quicker
> to reimplement them in Python, not least because it allows more complex
> functionality to be put straight in if we want it in the future. Then,
> we can always extend it so that some types of fields are implemented
> directly as triggers if you want once the API is settled.
>
> With all this in mind, my API proposal would be something like this:
>
> A CopiedField, called like so: user_username =
> models.CopiedField("user", "username") [here, "user" is the name of
> the ForeignKey to link through]
>
> An AggregateField: post_count =
> models.AggregateField(Post.objects.filter(visible=True), "count")
>
> The CopiedField essentially works how my current DenormField does, but
> using a foreignkey to avoid you having to specify both it _and_ the
> model if you have more than one to the same model (a reasonable amount
> of the DenormField code is just for finding which foreignkey to link
> through, anyway)
>
> The AggregateField takes a simple queryset (from which it can extract
> the model to hook a signal onto), and whenever something in the queryset
> is saved (so, either an extra select on each save to see what items are
> in the queryset, or just updating the aggregate every time - possibly
> with either selectable, since the cost might be higher on either), and
> it also takes the function to run on the set - either a builtin name
> like "count" here, or an actual function which takes a queryset and
> returns a result (in this situation the type of the underlying column
> will also have to be specified).
>
> This should probably cover most cases, and has the advantage of people
> being able to specify their own in-python aggregate functions (such as
> working out the standard deviation of the users' ages) if they tell us
> what kind of field to sling the result in.
>
> I'm happy to change the field names, too, CopiedField especially is a
> little clunky.
>
> Andrew
>
> >
>
--
David Cramer
Director of Technology
iBegin
http://www.ibegin.com/
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
