Hi All, Since last week, the new API has changed: we went from 5 field types to 9 field types. Below is a list of all field types, the bold ones are the ones that have just been added.
* pure data (CharField etc) * * relation data (FK)* * pure virtual (Point) * * relation virtual (GFK)* * m2m (badly named; nothing at present, but possibly in a document store) * * relation m2m (badly named; M2M fields)* * related object (Reverse FK) * related m2m (Reverse M2M) * related virtual (GenericRelation) More information on the new API can be seen on my documentation server at: http://5.101.98.142:49156/ref/models/meta.html#module-django.db.models.options The old API can be seen at: http://5.101.98.142:49155/ref/models/meta.html#module-django.db.models.options I will be posting again as soon as benchmarks finish. In the meantime it would be great to have some feedback. Thanks, Daniel On Saturday, August 9, 2014 4:10:31 PM UTC+2, Daniel Pyrathon wrote: > > Hi All, > > This week I have been working on mainly 3 tasks: > > *- Formalizing the PR* > 2 days were dedicated on fixing all the small issues on the PR. I am now > ready for another review. > > *- Simplified the API for get_field* > There are 3 used combinations of get_field() in the entire Django codebase > > > - get_field(data=True, m2m=True) > 60% of the occurrences > - get_field(data=True, m2m=True, related_objects=True, > related_m2m=True, virtual=True) > 39.9% of the occurrences > - get_field(data=False, m2m=True) once only! (0.01% of occurrences). > > The new API replaces the first 2 cases by generalizing: > get_field(field_name, include_related=False, **kwargs). > The API is still 100% backwards compatible with the old API, until Django > 2.0. > > Benefits: > > - better and simpler API > - better memory management (caching) > > *The mailer* > As my final deadline is near, I continued working on the mailer. The > mailer is a custom store that allows Django admin and forms to interact > with the GMail API. > I have published the source code for this here: > https://github.com/PirosB3/django-mailer/ > While the code is still "a big hack", I aim on getting a PoC fully working > and then do some refactoring. This week I managed to get relations between > custom models working, *all using the new Options API! *The result is I > can now browse my mail through the admin panel! > > > <https://lh6.googleusercontent.com/-5lUx63hvlZw/U-Yprxl8AzI/AAAAAAAALg0/8qNh6qw3YtA/s1600/5512779.png> > *- Help me get people excited about this!* > The new Options API works, and allows developers to create custom stores. > This will allow us to create official NoSQL stores, SqlAlchemy stores, and > even a IMAP store. I think it's a great feature that has the potential to > make Django more decoupled and more powerful. > Said this, it still needs loads of work. And I am sure the API can still > improve. Let's get more people aware of the new possibilities and help me > make a better API: > > - You can retweet https://twitter.com/pirosb3/status/497701148665843715 > - You can review https://github.com/django/django/pull/2894 > > Thanks! > Daniel > > > > On Friday, August 8, 2014 6:37:06 PM UTC+2, Daniel Pyrathon wrote: >> >> >> >> On Wednesday, August 6, 2014 3:46:42 PM UTC+2, Tom Christie wrote: >>> >>> > This has been resolved by using the ImmutableList datastructure >>> >>> Looks fine. Behaviourally it's the same as a tuple, but with more >>> explicit errors if you attempt to modify it, which seems reasonable. >>> >>> Given that `.get_fields()` and `.fields` return `ImmutableList`, >>> presumably `.field_names`, `.concrete_fields` and `.local_concrete_fields` >>> should do as well right? >>> >> >> Of course, I am pushing a new version of this now >> >> >>> >>> > A tuple is *not* "just an immutable list". >>> >>> Interestingly, that's a point where we'd differ. In my mental model a >>> programming construct is defined *purely* by it's behaviour, with no room >>> for any 'conceptual' or 'theroretical' difference - as far as I'm concerned >>> an (unnamed) python tuple really *is* just an immutable python list. >>> >>> I think any further conversation on that is out of the scope of this >>> list, but I've heard both positions advocated, and figured it's an >>> interesting point to note. :) >>> >>> (And it does have the occasional impact on how we'd choose to write >>> documentation examples etc...) >>> >>> All the best & keep up the great work, >>> >>> Tom >>> >>> >>> On Wednesday, 6 August 2014 01:33:53 UTC+1, Russell Keith-Magee wrote: >>>> >>>> >>>> On Tue, Aug 5, 2014 at 12:54 AM, Łukasz Rekucki <[email protected]> >>>> wrote: >>>> >>>>> On 4 August 2014 16:14, Daniel Pyrathon <[email protected]> wrote: >>>>> > Hi All, >>>>> > >>>>> > This has been resolved by using the ImmutableList datastructure >>>>> > >>>>> > >>>>> https://github.com/PirosB3/django/blob/soc2014_meta_refactor_upgrade_flags_get_field_tree/django/db/models/options.py#L629 >>>>> > >>>>> >>>>> But why? What's the benefit over using a tuple? ImmutableList is not >>>>> even a list, because it inherits from tuple. >>>>> >>>> >>>> Communication. >>>> >>>> From a purist theoretical perspective, there shouldn't be any argument >>>> - the data we're talking about is a list. Lists have homogeneous elements; >>>> Tuples have heterogeneous elements, but have *positional* homogeneity. A >>>> "Point" is a tuple, because element 0 of the tuple "means" the x >>>> coordinate. A Database row is a tuple - The first element is the primary >>>> key (an integer), second is the "name" column (a string), and so on. >>>> >>>> A tuple is *not* "just an immutable list". >>>> >>>> From a pragmatic perspective, tuples are faster to work with, because >>>> they aren't carrying around all the baggage needed to support mutability. >>>> And, in this case, there is a risk of an end-user accidentally mutating >>>> the >>>> result of get_fields(), which, due to cache-related optimizations, means >>>> there's a risk of side effects. >>>> >>>> So - in this case, at a theoretical level, we are dealing with an list >>>> of homogeneous objects (fields) that must be either immutable, or copied >>>> every time it is used. Copying is a bit expensive (not *completely* >>>> prohibitive, but noticeable), so that means we need to look to >>>> immutability. At a theoretical I'm not wild about the fact that >>>> ImmutableList subclassing tuple - it should be subclassing *list* - but >>>> I'm >>>> willing to defer to pragmatism. Given that we're dealing with a relative >>>> internal detail that most users won't be exposed to, I'm willing to hold >>>> my >>>> nose and accept optimised solutions over theoretically pure solutions in >>>> the interests of *all* users having better performance. >>>> >>>> Yours, >>>> Russ Magee %-) >>>> >>>> -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. 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/ebbc10fb-2c29-4634-884e-5e30ee2fbcbe%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
