Awesome! I've been really enjoying playing around with your code so far—I'm actually building a small project off of it for fun—and the addition of ListFields has been one of the things I've been waiting for. Embedded documents is definitely also high on my list.
1) It would be awesome to have ListFields implemented for Postgres, and would seem to make a lot of sense to use the same API, but would that be able to handle multi-dimensional arrays? Well, I guess you could do something like models.ListField(models.ListField(models.IntField()))... 2) I've been using mongoengine a lot, and I really like the way that they handle ListFields and EmbeddedDocumentFields (both of which I use extensively and to great effect). So my votes for that sort of syntax. 3) Something about heterogenous lists just rubs me the wrong way, but it doesn't seem that useful if you've also got embedded documents/objects. If you have a models.ListField(models.EmbeddedDocumentField(MyEmbeddedDocument)), you can just make subclasses of MyEmbeddedDocument to handle the different cases and stick them all in the same ListField. This is one of the things that has totally made mongoengine a kick ass tool for me, so native support in Django would rock. 4) Hell if I know. :) On Thu, Jul 22, 2010 at 4:37 PM, Alex Gaynor <alex.gay...@gmail.com> wrote: > Hey all, > > As I said in my last update, this week I've been working on some > ListField stuff. So far I have a basic ListField implemented, with a > syntax of models.ListField(models.IntegerField()). However, there are > a number of questions that have cropped up: > > 1) Should support for PostgreSQL (and probably other DB) arrays be > implemented using this same API. > 2) How do we handle what MongoDB calls "embedded documents", these are > effectively a foreign key, except the data isn't stored in a remote > table, it is stored inline with the object. I'm considering a syntax > such as models.ListField(models.EmeddedObject(MyModel)), (this would > also allow just assigning an EmbeddedObject() to create a 1-1 field > effectively). Another proposal I've seen is just > models.ListField(MyModel), which is similar to the ForeignKey syntax. > I'd like to avoid using ForeignKeys themselves, as I think the name > makes it explicit that the object is foreign (i.e. it lives in another > table, collection in MongoDB parlance). > 3) Should support for heterogeneous lists be supported. > 4) Where should the List code ultimately live. Right now I put it in > django.db.models.fields.structures. > > Alex > > -- > "I disapprove of what you say, but I will defend to the death your > right to say it." -- Voltaire > "The people's good is the highest law." -- Cicero > "Code can always be simpler than you think, but never as simple as you > want" -- Me > > -- > 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<django-developers%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- Josh Ourisman www.joshourisman.com (301) 244-9674 Washington DC -- 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.
