Hi all, Just to add a data point regarding virtual fields.
We're using them in production in our open source media library ( https://github.com/onefinestay/django-mediacat/blob/master/mediacat/fields.py#L97-L119). Essentially, due to a number of issues, it wasn't practical to have references to image crops to be foreign keys. Instead we have an association table with object_content_type, object_id, crop_id and field_name. The virtual field allows us to have an API that looks very much like a foreign key, but behind-the-scenes does all the magic to give us the benefits we were looking for. In the previous link, you'll also be able to see the hack I used to get the custom field working properly in modelforms. We're also using them a lot in other projects to seamless bridging between database-backed models and other types, ie whenever we want something that looks like a database column as far as the model is concerned, but isn't one in reality. Regards, Andrew Ingram On 22 December 2014 at 14:50, Collin Anderson <cmawebs...@gmail.com> wrote: > Ditto. I'm ok with a tiny shim for GFK, and we should get the API right > for RelatedObject going forward, (as long as it's at least _possible_ to > detect which is which and write code that works on both 1.7 and 1.8). > > On Monday, December 22, 2014 9:29:15 AM UTC-5, Aymeric Augustin wrote: >> >> Hi Russell, >> >> 2014-12-22 8:39 GMT+01:00 Russell Keith-Magee <rus...@keith-magee.com>: >> >>> The question: Do we - >>> >>> 1) Accept this particular internal specific naming of GFK as a quirk >>> reflecting the limitations of contrib.admin >>> >>> 2) Try to nail down what a "virtual" field means, or find some >>> alternative flag to identify what "GFK" is a proxy for in this case. >>> >> >> I'm in favour of (1) mostly because of the YAGNI principle. Defining >> "virtual" without a concrete use case sounds hard. >> >> >> The question: Do we: >>> >>> 1) Accept this as a backwards incompatible change. >>> >>> 2) Accept the inconsistency in the new API. >>> >>> 3) Find a pair of names other than model/related_model to represent the >>> "subject/object" pair in fields >>> >> >> I'm also in favour of (1) because the point of a refactoring is to clean >> up inconsistencies. We can say something in the release notes to help >> people who have used the RelatedObject private API. >> >> >> Best, >> >> -- >> Aymeric. >> > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/13baaf10-2395-47f6-8d1a-3a3b1543b7ff%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/13baaf10-2395-47f6-8d1a-3a3b1543b7ff%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAOA51CU4gZRSbjL56_oD2ZGNEXq9%2BriVZ%3DT9EWbdzRqqSKsykg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
