Just want to step out of lurker mode and pipe up with my modest +1.
I've been able to hack together simple denorm tricks for FK fields and
static data that work something like these fields -- but one thing I could
really use some help with yet is pulling off denormalization of frequently
changing
Christian Schilling wrote:
> yes, i merged that, ran my old tests against the fixed version and
> found a bug in the fix..
> so, i recreated the scenario in the new testsuite and fixed the
> fix ;-)
>
Ah, the wonderful meta-loop of fix fixes.
> i think we should really setup a trac instance
On Nov 30, 12:54 am, Andrew Godwin <[EMAIL PROTECTED]> wrote:
> The unit test 'suite' is hardly finished yet (one test...), but it does
> at least do a pretty thorough use check of some of the more basic
> scenarios. ./manage.py test denorm does indeed test and come out OK,
> though - it even
Christian Schilling wrote:
> I think the problem here is that you need to alter a model after
> django has initialized it, because there is just no other way to auto-
> detect
> the field-type of the mirrored field. So eliminating the need to type
> both the related model name as well as the
On Nov 28, 5:30 pm, Andrew Godwin <[EMAIL PROTECTED]> wrote:
>
> One: This is the MirrorField equivalent in the example:
>
> @denormalized(models.CharField,max_length=100)
> @depend_on_related(User)
> def owner_username(self):
> return self.owner.username
>
> While it's
So, I've had a good look over the (constantly-growing!) code here, and
I'm really beginning to like the decorator approach, especially the nice
way you combine dependencies with the dependency classes, which makes my
solution to old/new FK values look terrible.
I still have two issues, although
i spend some time implementing my idea above (still just a proof of
concept, all testing i did was on the example project)
the resulting models.py: (still in the same place)
http://github.com/initcrash/django-denorm/tree/master/example%2Fgallery%2Fmodels.py
as you can see, this makes the
Christian Schilling wrote:
> i don't think so.
> if you mean lines 35-38 in fields.py:
> this is only used to rebuild all denormalized values in the whole DB
> via the management command, witch means everything needs to be updated.
>
Ah yes, ignore me. I was trying to see how you did
one more thing...
On Nov 23, 12:00 pm, Andrew Godwin <[EMAIL PROTECTED]> wrote:
> Additionally, your code loops over every model every time, whereas in
> some cases you can detect which specific model needs updating (for
> example, if you know that the field "planet" on the just-saved object is
I think it would be even nicer if the function passed into the
decorator could
actualy return the new value of the field, instead of assigning it and
call save().
Currenty the function does two tasks:
1) figure out what needs to be updated "resolve dependenys"
2) calculate the new value
maybe the
Hmm, now that's an interesting implementation. I'm pleased to see you've
essentially taken the same route I did in terms of detecting when to
save, which means I'm not being as silly as I first thought.
The decorator syntax is nice, and certainly something that should be
around - however, I
i just implemented something like this. it useses decorator-syntax
to create a denormalized field from a callable.
i think the advantages of this aproach are:
1) it's very flexible
2) all code related to the denormalisiation is located in one central
place,
and not one place for the field
David Cramer wrote:
> I'm not sure on AggreateField either. What if you just do like
> ("Photo", "user__exact=self.user") or something. Currently there's no
> rerepsentation for "self" in Django QuerySet's, so this is a hard
> thing to call. Also, we need a way to support callables.
>
> e.g.
I'm not sure on AggreateField either. What if you just do like
("Photo", "user__exact=self.user") or something. Currently there's no
rerepsentation for "self" in Django QuerySet's, so this is a hard
thing to call. Also, we need a way to support callables.
e.g.
A Mele wrote:
> I have followed the discussions about denormalization and I really
> would like to see this in trunk. I agree with Rusell, the syntax
> should be more like Django's query syntax, but I think this kind of
> field is very useful for a lot of projects.
>
I obviously agree, but
I have followed the discussions about denormalization and I really
would like to see this in trunk. I agree with Rusell, the syntax
should be more like Django's query syntax, but I think this kind of
field is very useful for a lot of projects.
A Mele
On 27 oct, 13:26, Andrew Godwin <[EMAIL
Russell Keith-Magee wrote:
> I do have a slight reservation regarding the API you are proposing.
> The fields you have proposed (MirrorField and AggregateField) capture
> the obvious use cases, but the syntax don't feel consistent with the
> rest of the Django API. In particular, AggregateField
On Mon, Oct 27, 2008 at 8:05 AM, Andrew Godwin <[EMAIL PROTECTED]> wrote:
>
> class User(models.Model):
>username = models.CharField(max_length=255)
>email = models.TextField()
>num_photos = models.AggregateField("Photo", "fk:user", "count")
>num_all_photos =
So, after the general, soft consensus of
http://groups.google.com/group/django-developers/browse_thread/thread/9a672d5bbbe67562/248e53722acab49e,
I've put my money (or should that be time?) where my mouth is and
actually coded my suggested solution.
The current diff against trunk is attached -
19 matches
Mail list logo
