On Sun, Apr 03, 2011 at 03:08:51PM -0400, Alex Gaynor wrote: > Like Carl I haven't had time to properly read this, but one important thing > (IMO) to think about is not just having composite field support, but support > for "virtual" fields in general, that is fields that don't map to a database > column. This is for things like serialization, querying, forms, etc. (you > know all the places we use metadata).
Now I'm not sure I understand what exactly you have in mind. Just being able to have them in models and not breaking the things you mentioned or adding some special support? As for serialization, currently I don't see any mechanism that could tell the serializers to skip certain fields. This would probably be required to handle them cleanly. Of course, this could be hacked around by returning something like None or an empty string from value_to_string and ignoring the value in raw saves, but a mechanism in the serializers would be nicer, I think. As for querying, I think I already found out how to implement this. I'll post a reply to my original mail since I find it more appropriate to answer the question I asked there. (I hope I'm not creating too much noise here. (-: ) About forms, explicit virtual fields should be ignored altogether by default except for ForeignKeys (generic and regular ones) which should behave, well, as GFKs and regular ForeignKeys as they do now. This is where the same encoding as proposed for admin URLs could be used to pass the actual value. Nevertheless, I'm not sure what you mean by "all the places we use metadata". Having taken a quick look at the documentation index, I don't see any relevant topic I haven't mentioned in previous e-mails, however, that doesn't mean I haven't overlooked something. Michal Petrucha
signature.asc
Description: Digital signature
