On Fri, Jul 23, 2010 at 12:59 AM, Russell Keith-Magee <russ...@keith-magee.com> wrote: > 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)? >
Yes, there's a distinction. I could have a user with a list of addresses, or a single address (not just a list with 1 item). These are semantically different, so Embedded documents are distinct from ListFields. > 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? > Probably, an EmbeddedDocument inside of a ListField wouldn't really know what owns it. > 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. > EmbeddedForeignKey sounds like a contradiction, how can it be embedded AND foreign. > 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? > No, right now the ListField constructor takes the field type it stores, so addresses = ListField(EmbeddedModel(Address)) would just work. >> 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? > Yes, a further problem that occurs to be is that for EmbeddedModels we'd want to support polymorphism, but that means storing some auxilliary data as to what model a given thing is (this problem only occured to me as I started writing a bunch of tests for this).. This requires some further thought. >> 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. > > 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. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
