> if you can work on drafting a call that would be great
Sure, sounds like a sensible place to start.
I won't get onto anything immediately, but I'll start to have a think about
spec'ing it out at some point.
(Other offers/progress on this from anyone also welcome in the meantime
tho')
> Why w
On Tue, Jun 14, 2016 at 3:03 PM, Tom Christie
wrote:
> > we don't have a mechanism to delegate the "what should we build" part of
> the question for work other than channels.
>
> I guess there's two aspects to that.
>
> 1. Do Mozilla allow some flex in meeting the proposal / do we have an
> diffe
> we don't have a mechanism to delegate the "what should we build" part of
the question for work other than channels.
I guess there's two aspects to that.
1. Do Mozilla allow some flex in meeting the proposal / do we have an
differing priorities now / do we want to discuss what those should be?
Hi Tom -
This is a great question, and thanks for asking it. The short version is
"we're not quite sure yet, and we need to work this bit out."
To go into more details, first I need to explain a bit about how the MOSS
committee (of which I'm a part) works, and what it is and isn't doing.
Specifi
Do the Django MOSS committee have any plans for the request
parsing/response rendering portion of the Django MOSS proposal?
I'm assuming that any of the following could be reasonable choices:
* Expecting to issue a call for work in due course, but treating channels
as the priority for now.
* De
Hi all, I'd like to introduce a new feature to django urlresolver.
Currently, django urlresolver can only handle the path_info field of
request object.
code from django.core.handlers.base.BaseHandler.get_response
callback, callback_args, callback_kwargs = resolver.resolve(request.
path_info)
I
I agree with you Shai, that's why I proposed a command that makes use of
migrations internals (not to use a migration per se) to do the job.
Thanks for the feedback Marc, I know having the migration to use django orm
is a much slower process than importing it from a textual source, but the
main ob
Hi Bruno,
I think that putting such an operation in a migration doesn't make much sense.
If it's part of the project migrations, it means that the canonical way to set
up the database is to start up on MySQL and move to PG later. This is almost
surely not what you intend.
Copying data across
I'd suggest your approach is also quite slow. Andrew Godwin did something
similar once at a lower level - see
https://github.com/lanyrd/mysql-postgresql-converter (use at your own risk)
On 10 June 2016 at 19:44, Bruno Ribeiro da Silva
wrote:
> The problem here is that this works well for small d
