Whoops... hadn't noticed this was sent to multiple lists, so only replied to the first one.
Sending my technical discussion reply to django-dev, since that's where the main audience participation is likely to be. -------- Forwarded Message -------- From: Malcolm Tredinnick <malc...@pointy-stick.com> Reply-to: django-g...@googlegroups.com To: django-g...@googlegroups.com Subject: Re: [GSoC] Serialization Refactor Date: Sat, 21 Mar 2009 13:46:21 +1100 On Sat, 2009-03-21 at 01:38 +0530, Madhusudan C.S wrote: > Hi all, > I just wrote 2 mails about myself and my wish to > participate in GSoC as a Django student. Sorry if I am > spamming your inboxes. I just want to keep my mails short > so people who don't want to read everything in there can > skip the mails that are irrelevant to them. Please correct > me where ever I am wrong and if I am not doing it the > way it must be done here in Django. > > I hope I understand what Malcolm and Jacob meant when > they said this. > > We make changes because there are use-cases > for them, not because we can. So any proposal should > be driven by trying to fix some existing problem, not > creating a "wouldn't it be nice if...?" situation. > > I want to work on Serialization Refactor for GSoC. Since what > the Django community requires exactly from that idea is still > not clear to me, I am requesting any of you to explain a bit > on what is expected of that project? Yes, that seems to be the problem here (in fact, it was what I was thinking to myself when reading your second mail). I thought this problem was going to arise. The one-line suggestions on the SoC wiki page aren't particularly specific, unfortunately. They also aren't QA'd in any real way for practicality or difficulty, so it's a bit of a combination of wishlist and brainstorming. A starting point for further research, really. The confusion there is our fault, but if you view it as a starting point for thinking, that will be a good point. That particular item appears to be very poorly named in the wiki page. It's not about refactoring at all (which is changing code around to make new functionality easier, or remove redundancy). It's about adding new features to the serializers. Enhancing, extending and changing in various places, not refactoring. Now, there are a bunch of things that could be worked on in the serialization space. Have a look at the currently open tickets in that area (I mean, read them *all*): http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&component=Serialization&order=priority You'll see a few consistent patterns for feature requests and awkwardness there (beyond the things that are just basic bugs we have to fix at some point). It's also worth having a look at mailing list posts (and tickets) that refer to "fixtures", since that's where those things are used in Django. You'll start to see problems there with items like content type values changing or references to pk value in other models that change upon loading. We'd like to change the serialisation format to be a lot more robust when it's referring to other models in any way. One possibility is to use a label instead of a value for those fields. It can even be designed to be backwards compatible (by adding a version field to any new format). Adding support for non-model fields to be serialised is another option. Most of the things I see on the DjangoFullSerializers project appear to be covered in the tickets in Trac. So the question then becomes whether the goal would be to merge in DjangoFullSerializers, but keeping things backwards compatible for existing users. Or to take the good ideas and merge them in in a more piecemeal fashion. Or work through the general problems raised in the serializer and fixture tickets and posts on the mailing list. Hopefully that gives you a bunch of ideas for a bit more research. [...] > > So the solution that appears to me now is to add a > Serialization Field support to Django Models. Say something > like JSONField and provide Meta Data for the JSON Field > Structure in some way, say defining a class for its structure > (as we do for ModelAdmin) or providing this in Class Meta > inside the Model Definition. This can be done since we will > already, at least, know what will be the format of serialized > data we recieve (quite obvious, we need to know this, since > we cannot process any random serialized data). Hope this is > somewhat similar in idea to what is pointed out as ModelAdmin > in the ideas list on the wiki page. Hmm .. fields that provide serialized data aren't really anything to do with the serializer. You can already write them now. In fact, people have. I'm not sure where Meta factors into this, either. Writing a new custom field type isn't really Summer of Code project (it's Weekend of Code difficulty, really). > > I would like to add support for JSON and Python serialization > through this project during Summer Of Code period and take > take up XML and YAML post GSoC since I feel if we include > those also it would be too much for 12 weeks project. Just > my estimate :( Any serializers changes would really address all four formats at once, since the differences are very minor. Work in that area is really 90% getting it working for one type and then 10% getting it working for everything else, since converting to string format and converting from string format to internal object format are the very last and very first things, respectively, done by serialization and deserialization. Have a look at the existing code -- if you're going to work on serialization, it's probably not too much to hope you've actually looked at the code we have now -- and you'll see that the specific format classes don't do much extra work at all. The heavy lifting is in methods that work with the internal data structures. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
