[Prev] Thread [Next]  |  [Prev] Date [Next]

Re: Proposal: upgrading the choices machinery for Django Stephen Burrows Wed Apr 04 23:00:19 2012

I generally like this idea, except for the implicit integer ids based
on declaration order. As people have said, it seems like just asking
for data corruption. I'd much rather see implicit character ids based
on the attribute name of the choice, analogous to django fields.

Will you be making this project available as a third-party app?


On Apr 4, 5:41 pm, Alex Ogier <[EMAIL PROTECTED]> wrote:
> On Wed, Apr 4, 2012 at 5:18 PM, Łukasz Langa <[EMAIL PROTECTED]> wrote:
> > Wiadomość napisana przez Daniel Greenfeld w dniu 4 kwi 2012, o godz. 22:48:
> > > On two occasions now I've had to do serious debugging on implementations
> > done by other people who used a technique not dissimilar to what Łukasz
> > proposes. In both cases, while the inheritance and better control
> > structures were nice, the issue was that if you give people enough rope to
> > hang themselves, they will.
> > Can you elaborate on that a bit? Even if the proposal is rejected in the
> > end, I might use your experience to at least make the rope less deadly.
> I imagine a big one is that without an explicit database representation for
> every item, it is easy to get out of sync with the real data you have. And
> when that happens, there isn't necessarily a good way of retrieving the
> meaning of old data: if some data in your database says that you are using
> license '302' but that index was implicitly auto-generated by the
> particular ordering of Choice() instantiations, then when the ordering
> changes you can lose track (and indexing based on an implicit ordering of
> class attributes definitely seems shaky to me).
> When I use enumerated fields, I generally make them VARCHAR(10) or so, and
> then use plain English, potentially abbreviated, for a database
> representation. That makes for reasonable code, "if self.license ==
> 'gpl_any':" looks very readable to me, and doesn't restrict you from
> altering display values for internationalization.
> It seems to me like this is really a documentation problem, where
> distilling the wisdom of developers like Adrian into a little best
> practices paragraph in the choices argument reference would go very far in
> making the awkwardness go away.
> Best,
> Alex Ogier

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to [EMAIL PROTECTED]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at