Re: Proposal for new field type: CompositeField

2009-12-26 Thread Michael P. Jung
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

Re: Proposal for new field type: CompositeField

2009-12-26 Thread Michael P. Jung
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

Re: Proposal for new field type: CompositeField

2009-12-25 Thread Andy Mikhailenko
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

Re: Proposal for new field type: CompositeField

2009-12-25 Thread VernonCole
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 '

Re: Proposal for new field type: CompositeField

2009-12-24 Thread Jerome Leclanche
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

Re: Proposal for new field type: CompositeField

2009-12-24 Thread Michael P. Jung
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

Re: Proposal for new field type: CompositeField

2009-12-24 Thread Stephen Crosby
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

Proposal for new field type: CompositeField

2009-12-24 Thread Michael P. Jung
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