Hi Aymeric, Thanks for writing back
On Sunday, August 3, 2014 4:24:27 PM UTC+2, Aymeric Augustin wrote: > > On 3 août 2014, at 15:11, Daniel Pyrathon <[email protected] <javascript:>> > wrote: > > *1) get_fields should return a list instead of a tuple* > Previously, get_fields would return a tuple. The main reason was related > to memory and immutability. After discussing with Russell, we decided this > endpoint should actually return a list as it is a more suited data > structure. > > > Can you clarify the reasons for this choice? If it’s just the purity of > using the “proper” data type, I’m not sure it beats the practicality of > returning an immutable iterable and avoiding the cost of a copy or the risk > of incorrect manipulation. > This is a design decision, tuple performs better. > > The bugs that would occur if the cached value is altered inadvertently > could be very hard to track down. > Only a couple of days... https://github.com/PirosB3/django/commit/2411ff58d032c38a3151c1e54198723a86e6a8af > > *2) Move tree cache out of the apps registry* > The main optimisation for the new API (described here > https://code.djangoproject.com/wiki/new_meta_api#Mainoptimizationpoints) > is currently storing information on the Apps registry. After discussing > with Russell we agree this shouldn't be the correct place to keep this. > > > +1 > > A solution is to store related fields information separately on each model > ( > https://github.com/PirosB3/django/pull/5/files#diff-98e98c694c90e830f918eb5279134ab9R275). > > This has been done, and all tests pass. > Unfortunately, there are performance implications with this approach: we > are storing a new list on each model regardless of if it has related fields > or not. I will be discussing with Russell about performance tomorrow. > > > Is the extra cost incurred only at start up ? How large is it? If it isn’t > too bad and and run time performance is unchanged, it could be acceptable. > Yes! only at start-up. Once cache warming has finished, everything should be as fast (maybe faster, given that we are accessing properties on the single Options instance). > > *3) Revisiting field types and options* > Last week I opened this: > https://groups.google.com/forum/#!topic/django-developers/s2Lp2lTEjAE in > order to discuss with the community possible new field and option names. > This week I have actually revisited the fields and options for get_field/s > and I have come up with the following: (…) > > > The latest iteration looks clear, consistent and straightforward. I like > it. > Thanks! Please feel free to comment with doubts or suggestions. > > -- > Aymeric. > > -- 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/43fd8da7-b233-4914-8df8-14314276b1f0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
