Re: [GSoC] Composite fields: proposal, part 1

Am 06.04.2011 um 02:45 schrieb Michal Petrucha: [snip] > unique and db_index > ~~~ > Implementing these will require some modifications in the backend code. > The table creation code will have to handle virtual fields as well as > local fields in the table creation and index

Re: Customizable Serialization Proposal

> The purpose of this project is to define (and then implement) a DSL > for serialization. If a DSL is what you are looking for, then I withdraw my proposal. The idea of hosting yet another DSL inside Django project scares me a little. I'll just implement my idea as a separate project, I guess.

Re: Customizable Serialization Proposal

On Wed, Apr 6, 2011 at 11:31 AM, DaNmarner wrote: >> So - show me what it would look like. Show me how I, as a third party, >> would use your proposed syntax to define output that would match >> Django's existing serialization scheme. Yes, this serialization format >> will

Re: Customizable Serialization Proposal

> So - show me what it would look like. Show me how I, as a third party, > would use your proposed syntax to define output that would match > Django's existing serialization scheme. Yes, this serialization format > will exist as a built in default; but I should be able to reproduce > that format

Re: [GSoC] Composite fields: proposal, part 1

I started writing the draft for a full proposal, however, I don't have time to finish it today as I have to revise for tomorrow's exam. I will try to finish it in 12 hours at most since I know I'm already posting it a little bit too late to make it possible to review it thoroughly. Anyway, I'll

Re: Customizable Serialization Proposal

On Wed, Apr 6, 2011 at 7:44 AM, DaNmarner wrote: >> 1) It's almost illegible. Between your mail client's munging of line >> wrapping, and the completely unreadable code samples, it's very >> difficult to tell if you have presented a good idea. > > Pardon the format. I

Re: Customizable Serialization Proposal

As a side note: I encountered the use case for customizing serialization last summer when building my own blog project (I wanted an app that could import/export my models from/to wordpress/blogger XML. The API I proposed largely emerged from my thought back then. I'm willing to commit efforts to

Re: Customizable Serialization Proposal

> 1) It's almost illegible. Between your mail client's munging of line > wrapping, and the completely unreadable code samples, it's very > difficult to tell if you have presented a good idea. Pardon the format. I actually auto-wrapped the text with vim and copy pasted at the first time. Realizing

Sprints DjangoCon Europe

Nice!!! But, at over 500 euros, and the hotel costing 140 euros per night, I probably won't be able to attend.. (just simply can't justify spending 1000 euros on a conference, no matter how awesome it is lol). I'll look forward to seeing the slides / pictures though! Cal On Tue, Apr 5, 2011 at

Sprints DjangoCon Europe

Hi all, I'm sure you've all heard of the upcoming DjangoCon Europe. Of special interest to Django Developers will be the sprints, on the 9th & 10th of June. We've got a very special location: http://djangocon.eu/venues/#sprint_venue Of further interest: the sprints will run for 48 hours

Re: Prepared statements proof of concept

On Sat, Apr 2, 2011 at 10:04 PM, Marti Raudsepp wrote: > Hi list, > > I wrote a proof of concept patch to add prepared statement support to > Django for the PostgreSQL backend. Note that it's just a hack to see > if this approach could work at all, I know it's badly written. :) >

Re: Customizable Serialization Proposal

On Sun, Apr 3, 2011 at 6:58 AM, DaNmarner wrote: > I've got some more crystalized details about my proposal. > > Here are the target result if this proposal is implementated: > > 1. User could configure serialization for each model. > > 2. In fact, user could configure the

Re: Customizable Serialization

On Thu, Mar 31, 2011 at 7:38 PM, Vivek Narayanan wrote: > Hi Russ, > > Thanks for the suggestions once again, I've thought of changing the > model for handling nested fields. > > Each model can have a no of serializers, and they can be plugged in to > other serializers > and in

Using OneToOneField in reverse from values or values_list is rejected with "Invalid field name" (repost)

My apologies for reposting this - I originally posted this at the end of January and as soon as I posted it I realised that with the push for bug squashing for the 1.3 release going on I probably wouldn't get any attention (and thus comment or replies :), so I'm trying a repost now that 1.3 is

Re: [GSoC] Revised form rendering

On Sun, Apr 3, 2011 at 11:46 PM, Gregor Müllegger wrote: > Hi, > > 2011/4/2 Russell Keith-Magee : >> On Fri, Apr 1, 2011 at 11:57 PM, Gregor Müllegger >> wrote: >> Firstly, while it looks fine for a small example, I can see

Re: Fixing makemessages for Javascript

Jannis and Łukasz have both suggested the same thing: use Babel instead of xgettext. I understand why: it's a more complete solution than what I have proposed, which is at heart still a way to trick xgettext into parsing source code it doesn't natively understand. I have no experience with

Re: HttpRequest.read() issues

I've created two tickets for this, with patches and tests... http://code.djangoproject.com/ticket/15762 - WSGIRequest should wrap the test client wsgi.input in LimitedStream http://code.djangoproject.com/ticket/15763 - MultiPartParser's LimitBytes is now redundant. It's possible that I've