Re: Call for Channels work

[Tom Christie]

> 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 would this write you out of pitching for it, though?

Yes, fair point.

  - Tom

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/19d8ca9f-723b-4374-add6-81ede20312e5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Call for Channels work

[Andrew Godwin]

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
> differing priorities now / do we want to discuss what those should be?
>

We're allowed some flex as long as it's roughly within the bounds, is my
understanding; certainly I would say as long as we meet the terms of the
proposal (implementing request/response improvements) we're good.


> 2. Breaking down request parsing/response rendering, as initially
> described in the proposal, into a call for work. (Assuming we do want to
> include it?)
>

Yes, we need to; I just don't have the bandwidth to manage the work calls
for that as well as the Channels side.


>
> Given the release timelines I don't think we're in any great rush to make
> decisions here - 1.11 isn't due til April '17.
>
> Couple of options:
>
> * Plan to make a firm decision at the core team meeting in Django Under
> the Hood, having solicited feedback more widely first?
> * I could take on drafting up a call for work on the request/response
> portion. If there's a strong applicant for it, then we'd have plenty of
> time for it to start making its way in, without being remotely up against
> an alpha release deadline. (That way around would rather write me out of
> being an applicant, but might work well if we get the right person on
> board, and there might be scope for an a review/advisory role from Tim or
> myself)
>
> No firm opinions at this point, myself.
>
>
I'd like us to get going on this earlier than November, but I can't offer
much extra time towards it; if you can work on drafting a call that would
be great. Why would this write you out of pitching for it, though?

Andrew

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFwN1urjd7bp%3Dr6jnq8b%3DuwHHLX-oKuRCPWTw4ax-Bo%2BS_CQnQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Call for Channels work

[Tom Christie]

> 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?
2. Breaking down request parsing/response rendering, as initially described 
in the proposal, into a call for work. (Assuming we do want to include it?)

Given the release timelines I don't think we're in any great rush to make 
decisions here - 1.11 isn't due til April '17.

Couple of options:

* Plan to make a firm decision at the core team meeting in Django Under the 
Hood, having solicited feedback more widely first?
* I could take on drafting up a call for work on the request/response 
portion. If there's a strong applicant for it, then we'd have plenty of 
time for it to start making its way in, without being remotely up against 
an alpha release deadline. (That way around would rather write me out of 
being an applicant, but might work well if we get the right person on 
board, and there might be scope for an a review/advisory role from Tim or 
myself)

No firm opinions at this point, myself.

  Tom

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c5e5e0e0-894d-4580-9a1a-2fa9267e334b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Call for Channels work

[Jacob Kaplan-Moss]

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.

Specifically, I want to note that we're *not* making technical decisions.
So when it comes to Channels work, Andrew is the "technical lead" (for want
of a better term), so delegating decisions about what to do to him. Our job
is to ensure that we're spending the MOSS money effectively, so what we do
is:

- review proposals to make sure we believe the person is capable of
completing the work they've proposed, and that the budget they're proposing
is reasonable (this is very similar to how we might review a GSoC proposal,
with the added wrinkle of reviewing financial quotes)
- review the completed work to double-check that the task is complete
- coordinate between people doing the work and the DSF to get invoices paid

You'll note that nowhere are we deciding things like "should this thing be
built?" -- we're judging "can this person build the thing, and are they
charging appropriately for their work?". This is a fairly deliberate
choice, which mimics the way the DSF doesn't tell the core developer team
what to build, but instead tries to spend its money in a way that helps the
core team build what they want to build.

So here's where things get sticky: what do we do about non-Channels work?
As you note, the MOSS money was earmarked for more than just Channels. But,
we don't have a mechanism to delegate the "what should we build" part of
the question for work other than channels.

We need to work this part out, and I'll take ownership of finding an answer
here. If you have any suggestions, I would really love to hear 'em.

Jacob

On Tue, Jun 14, 2016 at 6:58 AM, Tom Christie 
wrote:

> 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.
> * Defer any decisions on it until the channels portion is deemed
> sufficiently complete.
> * Decide that it's no longer regarded as a priority and use the resource
> elsewhere.
> * Decide that it would conflict with the REST framework MOSS grant and use
> the resource elsewhere.
>
> Asking more from a stand-point of transparency, than trying to push for a
> 'call for work' to be issued.
> Personally, the second option on that list probably sounds like the best
> overall choice at the moment, but I think any could be valid.
>
> Cheers,
>
>   Tom
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/f1b3bf18-b8dd-49c9-8b34-9125a2ff9d6e%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAK8PqJEFW0DC8_qbwCz827grP9bDqqhbgY_yxsM67ZYWdKSSFw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Call for Channels work

[Tom Christie]

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.
* Defer any decisions on it until the channels portion is deemed 
sufficiently complete.
* Decide that it's no longer regarded as a priority and use the resource 
elsewhere.
* Decide that it would conflict with the REST framework MOSS grant and use 
the resource elsewhere.

Asking more from a stand-point of transparency, than trying to push for a 
'call for work' to be issued.
Personally, the second option on that list probably sounds like the best 
overall choice at the moment, but I think any could be valid.

Cheers,

  Tom

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f1b3bf18-b8dd-49c9-8b34-9125a2ff9d6e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

pass entire request object to urlresolver

[Elephant Liu]

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'd like to pass the entire request object to urlresolver so that I 
can implement more complex url resolving logic.
For example:
* base on path and http method
* base on path and http header (such as User-Agent)

I'd like to make a demo if you agree with my idea.

At last, forgive my bad English.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f5ff3d06-6a12-42f1-aae8-b260e71256f9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Use migrations api to create a command for data migration between different databases

[Bruno Ribeiro da Silva]

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 objective is the correctness of the data. Using django orm would
guarantee that all the tables are created the way django expects it and the
data is inserted into the database as well as the way django does it.

My concern is migrate without having to change anything on the models or
get an unexpected behavior.

Thanks for all your feedback, I'm gonna try to have some PoC and see if
it's doable.

On Tue, Jun 14, 2016 at 8:43 AM, Shai Berger  wrote:

> 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 is usually a one-time thing, not something you want as
> part of your living history. A management command fits much better than a
> migration.
>
> My 2 cents,
> Shai
>
> On 10 ביוני 2016 20:47:51 GMT+03:00, Bruno Ribeiro da Silva <
> bruno.dev...@gmail.com> wrote:
>>
>> Hey guys, I'm not sure if I should be asking this here, but it's related
>> to django internals.
>>
>> I have this idea to create a command that uses the migrations api to
>> migrate all the data from one database (eg. MySQL) to another database
>> (PostgreSQL).
>>
>> So I would run the migrations in the new target database, then flush all
>> the tables there, and model by model do a bunch of bulk_create into the new
>> database using the result queryset from the source database.
>>
>>
>> The questions are: do you think it is feasible to make all of this inside
>> a command? If I have to change the migrations api to make it happen, do you
>> think this could be a nice feature to have in Django?
>>
>>
>> Thanks in advance!
>>
>>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/9B1A79E7-E458-4DA5-BC94-C1838DA4908E%40platonix.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Bruno Ribeiro da Silva
Python Dev and Homebrewer!

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAE-2%3DJyeqJMwkh%3Dw-VA9b1ou4nz-juE9kwYvG5HJB5-AfRcKZQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Use migrations api to create a command for data migration between different databases

[Shai Berger]

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 is usually a one-time thing, not something you want as part 
of your living history. A management command fits much better than a migration. 

My 2 cents, 
Shai 

On 10 ביוני 2016 20:47:51 GMT+03:00, Bruno Ribeiro da Silva 
 wrote:
>Hey guys, I'm not sure if I should be asking this here, but it's
>related to 
>django internals.
>
>I have this idea to create a command that uses the migrations api to 
>migrate all the data from one database (eg. MySQL) to another database 
>(PostgreSQL).
>
>So I would run the migrations in the new target database, then flush
>all 
>the tables there, and model by model do a bunch of bulk_create into the
>new 
>database using the result queryset from the source database.
>
>
>The questions are: do you think it is feasible to make all of this
>inside a 
>command? If I have to change the migrations api to make it happen, do
>you 
>think this could be a nice feature to have in Django?
>
>
>Thanks in advance!
>
>-- 
>You received this message because you are subscribed to the Google
>Groups "Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
>To view this discussion on the web visit
>https://groups.google.com/d/msgid/django-developers/1f588512-dc82-4182-a87b-cbdabea71a11%40googlegroups.com.
>For more options, visit https://groups.google.com/d/optout.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/9B1A79E7-E458-4DA5-BC94-C1838DA4908E%40platonix.com.
For more options, visit https://groups.google.com/d/optout.

Re: Use migrations api to create a command for data migration between different databases

[Marc Tamlyn]

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 databases, but for
> bigger ones it uses too much memory and is a slow process.
>
> On Fri, Jun 10, 2016 at 3:22 PM, Stephen J. Butler <
> stephen.but...@gmail.com> wrote:
>
>> I usually just use dumpdata/loaddata to do these kinds of things.
>>
>> On Fri, Jun 10, 2016 at 12:47 PM, Bruno Ribeiro da Silva <
>> bruno.dev...@gmail.com> wrote:
>>
>>> Hey guys, I'm not sure if I should be asking this here, but it's related
>>> to django internals.
>>>
>>> I have this idea to create a command that uses the migrations api to
>>> migrate all the data from one database (eg. MySQL) to another database
>>> (PostgreSQL).
>>>
>>> So I would run the migrations in the new target database, then flush all
>>> the tables there, and model by model do a bunch of bulk_create into the new
>>> database using the result queryset from the source database.
>>>
>>>
>>> The questions are: do you think it is feasible to make all of this
>>> inside a command? If I have to change the migrations api to make it happen,
>>> do you think this could be a nice feature to have in Django?
>>>
>>>
>>> Thanks in advance!
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/1f588512-dc82-4182-a87b-cbdabea71a11%40googlegroups.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/CAD4ANxWFjR0FJimBrk-1WqEHYzw3hc%2Bf949u3DGhKexrmkM%3Deg%40mail.gmail.com
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Bruno Ribeiro da Silva
> Python Dev and Homebrewer!
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAE-2%3DJxMSXtLsF03OFBrF6CChTJL3AQDnJK_Q_u2AuktjSk5NQ%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1FTo_j17ETgNH6jyL%2BqsEqo5pv6kda7Z_tKFY2u%2Bk%2BfHQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.