I just implemented [1] the ComplexNumberField using the CompositeField
class. It also shows that it is possible to change subfield attributes
inside the __init__ method since the subfields are deep copied for every
instance.
I hope that the test cases are mostly complete. I plan on writing down
th
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
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 se
Let me give a hearty YES to this proposal. I have been told that a
composite field, like this, is a violation of good database design,
and that a 'true' relational database cannot have this feature. That
is why the guy who designed the database I helped implement in 1982
did not call his design '
I like it, always wondered if there was a way to do this in the core. Hope
the patch gets through.
J. Leclanche / Adys
On Fri, Dec 25, 2009 at 1:22 AM, Michael P. Jung wrote:
> On 2009-12-24 19:45, Stephen Crosby wrote:
> > In your address example, I'm not sure what advantage this
> > Composit
On 2009-12-24 19:45, Stephen Crosby wrote:
> In your address example, I'm not sure what advantage this
> CompositeField has over just creating an address model/table and
> using a regular foreign key to reference it. You mentioned the need
> to create a field composed of other fields which to me so
Michael,
In your address example, I'm not sure what advantage this CompositeField has
over just creating an address model/table and using a regular foreign key to
reference it. You mentioned the need to create a field composed of other
fields which to me sounds a lot like a regular one-to-many rel
Quite often I find myself in the need of fields composed of other
fields. e.g.
class AddressField(CompositeField):
addressee = models.CharField(max_length=50)
street = models.CharField(max_lenght=50)
zipcode = models.CharField(max_lenght=10)
# ... more fields he