On 2009-12-26 05:17, Andy Mikhailenko wrote:
> Maybe I'm missing something, but I don't understand how is this
> different from having a bunch of separate fields. The CompositeField
> adds a namespace, but foo.bar_x=1 seems to be no harder to read than
> foo.bar.x=1. I must admit that this field solves another problem
> well: it makes easier to copy sets of fields.
It's not just about copying sets of fields, but rather implement custom
types, which are separated into more than one database column. It's all
about not having to repeat yourself and ensuring consistency when using
those field types.
Another great example for a CompositeField is the LocalizedField, which
I just completed and pushed [1] to the repository.
The implementation is pretty simple and makes defining columns, that
need translation a breeze. django-multilingual [2] solves the same thing
in a somewhat different way with extra tables.
On 2009-12-26 05:17, Andy Mikhailenko wrote:
> However, if this is done frequently, the chances are high that
> denormalization is what we actually need. So I think this field may
> be great in some use cases, but in most cases it would rather
> overcomplicate things. Feel free to ignore this comment if I'm
> missing the point :)
Denormalization is surely about to become a killer feature. Though it
has a somewhat different scope than composite fields.
Composite fields are about combining data that is never ment to be
separated, while denormalization is about speeding up database access.
Just think of complex numbers. I guess most people wouldn't implement it
using an intermediate table. And those who do are probably going to find
their code sooner or later at The Daily WTF [3]. ;-)
The more I think about this I feel that this could be the best example
for a CompositeField so far:
class ComplexNumberField(CompositeField):
real = models.IntegerField()
imag = models.IntegerField()
def get_proxy(self, model):
proxy = super(ComplexNumberField, self).get_proxy(model)
return complex(proxy.real, proxy.imag)
def set_all(self, model, value):
proxy = super(ComplexNumberField, self).get_proxy(model)
proxy.real = value.real
proxy.imag = value.imag
Accessing a field of the type ComplexNumberField will not return a
proxy, but rather a complex number. This is a special case since complex
is an immutable type. This also made me think that get_proxy shouldn't
be directly called from the property.
[1] https://hg.labs.terreon.de/common/chimes/rev/7d7059656f5d
[2] http://code.google.com/p/django-multilingual/
[3] http://thedailywtf.com/
--mp
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
