On Fri, Jul 23, 2010 at 4:37 AM, 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.
I'd argue yes, unless you can point at some significant semantic difference between a relational and noSQL interpretation of a list attribute. > 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). The semantics of a ForeignKey are different to the semantics of an embedded document, so I agree that the ForeignKey isn't appropriate here. As to a better syntax: Is there a distinction here between one and many embedded documents? Or are embedded documents always singular (or always plural)? Also - is this a case where we need to break the "point at your owner" metaphor that ForeignKey implements, in favor of a "point at your list of children" metaphor? If we're maintaining the ForeignKey metaphor, it sounds like something like EmbeddedForeignKey might be appropriate -- EFK would be defined the same way as a ForeignKey would be, but the 'embedded' bit lets you know that it's not a standalone document, but will become part of the parent document. If we're going with the alternative approach, then the single document case just needs something like an EmbeddedDocumentField. I'm not sure what the right response is in the plural case; is there a need to differentiate between a ListField (as described in point 1) and a ListField that describes an embedded document set? > 3) Should support for heterogeneous lists be supported. If they're supported on the backend, then it makes sense that they should be in the API. I'm guessing the issue is identifying the document type on retrieval so you can instantiate the appropriate object container? > 4) Where should the List code ultimately live. Right now I put it in > django.db.models.fields.structures. Sounds reasonable to me, at least as a starting point. Yours, Russ Magee %-) -- 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.
