Hi All, An update on my side, some interesting work has happened this week: me and Russell have decided to start on the implementation early in order to understand better the internals of Options. Currently I am working on the following:
*Providing one single function: get_fields(types, opts, **kwargs)* Previously we had identified a number of functions that contained similar data but had a different return type. We are going to provide one function that takes a set of field types + options and returns the same output everywhere: ((field_name, field), ...). This has the benefit of simplicity and is more maintainable than the previous approach. TYPES = DATA, M2M, FK, RELATED_OBJECT, RELATED_M2M OPTS = NONE, LOCAL_ONLY, CONCRETE, INCLUDE_HIDDEN, INCLUDE_PROXY, VIRTUAL *Providing two functions for retrieving details of a specific field* As specified in my previous document, in many parts of the code we just want to retrieve a field object by name, other times we have a field but need other metadata such as: owner (model_class), direct (bool), m2m (bool). We will provide two functions: get_field(field_name) -> field_instance get_field_details(field_instance) -> direct, m2m, (still to be defined) While we still have not entirely defined what *get_field_details *will return, this will be done soon. *Building a test suite for the existing API* The new API development will be driven by a test suite that will compare the current (legacy) API with the new implementation. While return types will be different, we are asserting that all the correct fields and metadata are returned. Building a test suite means we can start implementing before a final API spec is finalised. It also means we can iterate faster and, from my perspective, I also understand a lot more of the current implementation. We are testing each combination of fields and options together. My current implementation is visible here: https://github.com/PirosB3/django/compare/soc2014_meta_refactor For any questions or suggestions, let me know. Daniel Pyrathon On Monday, May 26, 2014 1:28:31 AM UTC+2, Daniel Pyrathon wrote: > > Hi All, > > Just to make you know, I have put up the current _meta API documentation > here: > http://162.219.6.191:8000/ref/models/meta.html?highlight=_meta > As always, feel free to ask questions. > > Daniel > > On Monday, May 26, 2014 1:26:27 AM UTC+2, Daniel Pyrathon wrote: >> >> Hi Josh, >> >> The meta API specified in the docs ( >> https://github.com/PirosB3/django/blob/meta_documentation/docs/ref/models/meta.txt) >> >> is the current API. I have documented this in order to understand more of >> the current implementation and it will be good to show a comparison when a >> new meta API will be approved. >> >> My current proposal (https://gist.github.com/PirosB3/371704ed40ed093d5a82) >> and it will be discussed tomorrow with Russell. I will post as soon as I >> have updates. >> >> Daniel Pyrathon >> >> On Saturday, May 24, 2014 10:37:49 AM UTC+2, Josh Smeaton wrote: >>> >>> Hi Daniel, >>> >>> Nice work putting that document together. Is the meta document you put >>> together the current API or is it the API you are proposing? If the latter, >>> a few suggestions (and if others disagree, please point that out): >>> >>> - Remove all mention of caching. That should be an implementation detail >>> only, and not a requirement for other implementations. >>> - the *_with_model methods really rub me up the wrong way. I would >>> prefer always returning the _with_model variant, and letting the caller >>> discard the model if they don't need it. >>> - I'm not a fan of virtual and concrete fields, though I have to admit >>> I'm not sure how they're different, especially in the context of different >>> implementations. >>> - Not sure that m2m should be differentiated from related. >>> - init_name_map should be an implementation detail. >>> - normalize_together should be an implementation detail. >>> >>> Regards, >>> >>> Josh >>> >>> On Saturday, 24 May 2014 05:05:02 UTC+10, Daniel Pyrathon wrote: >>>> >>>> Hi all, >>>> >>>> In the last days I have built a documentation of the current state of >>>> Options. Based on feedback and prototyping I have thought of a potential >>>> interface for _meta that can solve the issues currently present, such as >>>> redundancy (in code and in caching systems). The interface has also been >>>> thought to be maintainable and is a base that can be used to create custom >>>> meta stores. >>>> Obviously this is far from perfect, It will need many iterations and >>>> maybe it is too complex. I would really love to gain as much feedback as >>>> possible so it can be discussed with Russell and the community on Monday. >>>> >>>> The documentation of _meta can be found here: >>>> https://github.com/PirosB3/django/blob/meta_documentation/docs/ref/models/meta.txt >>>> I will be refining the document in the next days, I will also be >>>> publishing the docs on a webserver and will be linking a URL soon. >>>> >>>> My proposal has been published here: >>>> https://gist.github.com/PirosB3/371704ed40ed093d5a82 >>>> In the next days I will be iterating over the feedback gained, and >>>> based on one very interesting suggestion on IRC, I will try to see how my >>>> API syntax looks in modelforms.py. >>>> >>>> As said previously, and feedback is greatly appreciated. >>>> >>>> Hi from Pycon IT! >>>> >>>> Daniel Pyrathon >>>> >>>> On Tuesday, May 20, 2014 3:25:45 PM UTC+2, Josh Smeaton wrote: >>>>> >>>>> Best of luck! >>>>> >>>>> On Tuesday, 20 May 2014 03:56:06 UTC+10, Daniel Pyrathon wrote: >>>>>> >>>>>> Hi All, >>>>>> >>>>>> Today I will be starting my weekly updates on my SoC project: >>>>>> refactoring Meta to a stable API. For anyone who missed out, you will be >>>>>> able to view it here: >>>>>> https://docs.google.com/document/d/1yp2_skqkxyrc0egdRv6ofnRGCI9nmvxDFBkCXgy0Jwo/edit >>>>>> >>>>>> This week is the first official week of SoC. Me and my mentor >>>>>> (Russell) are initially approaching the work in the following way: >>>>>> >>>>>> - *Document the existing Meta API* >>>>>> For each endpoint, document the following: >>>>>> - Input parameters and return type >>>>>> - Caching pattern used >>>>>> - Where it's called from (internally and externally to Meta) >>>>>> - Why is it being called >>>>>> - When is it being called >>>>>> >>>>>> - *Propose an initial refactor plan* >>>>>> Once the documentation has been done, I should have a better idea >>>>>> of the current implementation. This will allow me to mock a proposed >>>>>> implementation that will be reviewed at my next update call, on >>>>>> Monday. >>>>>> >>>>>> My next update will be posted on Friday, just to make sure the >>>>>> community is informed of my progress. For any major updates that require >>>>>> community approval, I will be creating separate threads. >>>>>> My name on the internet is pirosb3, so if you want to have a chat >>>>>> about my progress feel free to contact me! The branch I am currently >>>>>> working on is >>>>>> https://github.com/PirosB3/django/tree/meta_documentation >>>>>> >>>>>> Regards, >>>>>> Daniel Pyrathon >>>>>> >>>>> >>>> On Tuesday, May 20, 2014 3:25:45 PM UTC+2, Josh Smeaton wrote: >>>>> >>>>> Best of luck! >>>>> >>>>> On Tuesday, 20 May 2014 03:56:06 UTC+10, Daniel Pyrathon wrote: >>>>>> >>>>>> Hi All, >>>>>> >>>>>> Today I will be starting my weekly updates on my SoC project: >>>>>> refactoring Meta to a stable API. For anyone who missed out, you will be >>>>>> able to view it here: >>>>>> https://docs.google.com/document/d/1yp2_skqkxyrc0egdRv6ofnRGCI9nmvxDFBkCXgy0Jwo/edit >>>>>> >>>>>> This week is the first official week of SoC. Me and my mentor >>>>>> (Russell) are initially approaching the work in the following way: >>>>>> >>>>>> - *Document the existing Meta API* >>>>>> For each endpoint, document the following: >>>>>> - Input parameters and return type >>>>>> - Caching pattern used >>>>>> - Where it's called from (internally and externally to Meta) >>>>>> - Why is it being called >>>>>> - When is it being called >>>>>> >>>>>> - *Propose an initial refactor plan* >>>>>> Once the documentation has been done, I should have a better idea >>>>>> of the current implementation. This will allow me to mock a proposed >>>>>> implementation that will be reviewed at my next update call, on >>>>>> Monday. >>>>>> >>>>>> My next update will be posted on Friday, just to make sure the >>>>>> community is informed of my progress. For any major updates that require >>>>>> community approval, I will be creating separate threads. >>>>>> My name on the internet is pirosb3, so if you want to have a chat >>>>>> about my progress feel free to contact me! The branch I am currently >>>>>> working on is >>>>>> https://github.com/PirosB3/django/tree/meta_documentation >>>>>> >>>>>> Regards, >>>>>> Daniel Pyrathon >>>>>> >>>>> -- 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 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/98bf861f-770c-4697-9632-c070c571ecd5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
