If I set ForeignKey as the sub field in ListField and try to set it as groups = [groups] I will get an exception.
InvalidId: AutoField (default primary key) values must be strings representing an ObjectId on MongoDB (got u'Group Name' instead)
In my experience, the expected functionality with a ForeignKey field in the DjangoORM is that I can use the objects in reference. This is how ForeignKey works elsewhere in nonrel and in Django itself.
When searching about this error I came across more than one person attempting to use ForeignKey in a ListField and having errors and problems. This is part of my attempt to make it work in the way I think people expect it to.
That maybe a reason not to do so. I would think though that the way that ForeignKey works in ListField being different from how it works outside ListField is the wrong default behavior. I wouldn't mind a way to just explicitly pull the list of ids.
The whole idea of a field acting differently because it's in a list hurts my nerd sensibilities.
I agree with keeping consistency. The thing about iterating a ListField of FKs being costly is a developer issue. If we make listfields manage objects (Normal FK Objects, so, Lazy ones) we'll make them consistent with the rest of the ORM, even though, the patch needs to be reworked.
I think, when the attribute is set, somehow translating it over using filter(pk__in = list_of_fks), might give us something lazy. That would essentially be a queryset.
I also think, that for those concern with speed, it wouldn't be bad to have a helper field ObjectIdField, a subclass of CharField set to 24 max_length and that verifies that the string conforms to an ObjectId. Just throwing that out there. I only know Mongo, so I don't know how this would affect GAE, etc.
I just don't think it's worth going down that rabbit hole. It would require too much effort to make this magically work such that we never execute unnecessary queries, never retrieve more entities than necessary, and cache everything automatically. Do we really want to do this just because it's a little bit nicer? It's not worth it.
It's more than nicer. It's how ForeignKey is supposed to work. We would not be adding new functionality, but fixing a bug. I have to agree with the statement that optimization is a developer issue. It doesn't have to be 100% optimized, just as much as reasonable.
Making sure contribute_to_class attaches correctly will solve a majority of the issues.
If ForeignKey won't be any more than CharField inside a list then it shouldn't be allowed to be used inside the list. Because it is broken. ForeignKey field is supposed to work with objects. It does that everywhere else in the ORM, except here. If it won't be supported, then it should raise a NotImplimented. In my opinion
ForeignKey uses contribute_to_class to attach ReverseSingleRelatedObjectDescriptor to the model as the attribute. In a ListField contribute is never called. That is probably fine, since I'm not sure if that is the direction to go since it would be hard to give it something to attach to.
The object descriptor does other things like trace down what the ForeignKey actually points to in case of inheritance and some other complex situations.