Proposal for contrib feature (DictionaryField in models)

[Mark Ferrer]

Hi everyone,

This is my first time here, and I've been holding on to some code for a custom model field type for a little while now. I call it a DictionaryField and it takes a Python dictionary object and stores it in a database as a text field. The default storage format is "key1=foo;key2=bar". The characters used as delimiters and key-value assignments can be changed by passing in a couple of arguments. When it's fetched from the database through the orm, the value comes back as a Python dictionary object. It correctly casts integers and floats.

It was recently used on a project to store custom user settings. I'm not sure what other uses it could potential have, but I was wondering if it's something that anyone else could use. If you guys think this would be a useful addition to the framework, I would be very happy to fix up the code to meet your documentation standards and style guide. If it's a crap idea that only an inbred monkey with half a brain would think up, then I'll make sure to keep it away from daylight.

Thanks,

Mark

[Javier Guerra]

On Tue, Aug 11, 2009 at 2:11 PM, Mark Ferrer<mvfe...@gmail.com> wrote:
> I call it a DictionaryField and it takes a Python dictionary object and
> stores it in a database as a text field

i usually just encode it as JSON. not as dense; but more universal
syntax, so you get faster decoders in every language

--
Javier

[Mark Ferrer]

You're right. I forgot about JSON. I guess it can be encoded and
stored as a JSON string and then decoded afterward.

On Aug 11, 3:19 pm, Javier Guerra <jav...@guerrag.com> wrote:

[Dave Jeffery]

On Tue, Aug 11, 2009 at 11:58 PM, Mark Ferrer <mvfe...@gmail.com> wrote:

You're right. I forgot about JSON. I guess it can be encoded and
stored as a JSON string and then decoded afterward.

See django-jsonfield: http://github.com/bradjasper/django-jsonfield/tree/master

Personally I use JSONField often and I find it quite handy, so I would be a +1 but a quick search will bring you to #5965 [1] where it was rejected for being "too specialised for core".

[1] http://code.djangoproject.com/ticket/5965

[Russell Keith-Magee]

On Wed, Aug 12, 2009 at 3:11 AM, Mark Ferrer<mvfe...@gmail.com> wrote:
> Hi everyone,
> This is my first time here, and I've been holding on to some code for a
> custom model field type for a little while now. I call it a DictionaryField
> and it takes a Python dictionary object and stores it in a database as a
> text field. The default storage format is "key1=foo;key2=bar". The
> characters used as delimiters and key-value assignments can be changed by
> passing in a couple of arguments. When it's fetched from the database
> through the orm, the value comes back as a Python dictionary object. It
> correctly casts integers and floats.

Suggesting this for contrib is premature. The basic criteria for
django.contrib is an optional, defacto standard implementation of
common patterns. I'm not convinced that this is a common pattern. I'm
also not convinced that it's a good pattern to promote in a world of
relational databases, but that's a whole different argument.

Regardless of my opinion, this is a feature that can happily live
external to the Django core. If you want to convince us to put this in
django.contrib, then release it as an external project and show us the
widespread use that your field receives. Numbers talk.

Yours,
Russ Magee %-)

[corn1...@gmail.com]

I would like to see the code for this. I have been waiting for something like it.

TIA

-- Sent from my Palm Pre

---

[Jerome Leclanche]

Might be slightly off-topic, but, if that's the main criterion, are we ever going to include django-tagging in contrib?
J. Leclanche / Adys

[Russell Keith-Magee]

On Wed, Aug 12, 2009 at 9:02 AM, Jerome Leclanche<ady...@gmail.com> wrote:
> Might be slightly off-topic, but, if that's the main criterion, are we ever
> going to include django-tagging in contrib?

"Ever" is a very long time. I wouldn't be surprised if _eventually_
django-tagging is added to django.contrib. It is certainly a better
candidate for inclusion into django.contrib than the DictField
proposal. However, that doesn't mean it will be added in v1.2.

Jacob addressed django-tagging directly in his blog entry about
django.contrib [1]. To the best of my knowledge, his comments still
hold.

Most importantly, django-tagging is in no way compromised by being
external to django.contrib. The same is true of django-registration,
django-profiles, and any number of other popular external packages.

[1] http://jacobian.org/writing/what-is-django-contrib/

Yours
Russ Magee %-)