Re: Allow impossible model validation (mainly admin and generic forms)

2015-11-25 Thread Podrigal, Aron
I'm also in favor of some solution here. I used to raise a ValidationError
with either a particular field if I was able to extract the particular
error via regex matches, or as non_field_errors. That was my best I had
instead of resulting in a 5xx. In most cases for example a unique race
condition, when the user will resubmit the form it will have the detailed
validation errors or pass.
On Nov 25, 2015 1:57 PM, "Tim Graham"  wrote:

> Would Django itself ever raise ValidationError in Model.save()?
>
> I wonder how you propose converting something like an IntegrityError from
> the database into an "friendly" exception for the user?
>
> On Wednesday, November 25, 2015 at 9:23:05 AM UTC-5, Vlastimil Zíma wrote:
>>
>> Django assumes that all input data in forms can be validated by
>> `Form.is_valid()` which in some cases is not true. Database contraints,
>> e.g. unique, can fail even though they are checked. An application may
>> require communication with other servers while processing data which can
>> lead to errors. But these conditions are not expected by regular Django
>> form flow and an attempt to handle these cases results in large overriding
>> of default implementation.
>>
>>
>> This topic was previously discussed here
>> https://groups.google.com/d/topic/django-developers/rzjpP0byNQo/discussion,
>> but discussion was mainly based on race condition in unique check. I'd like
>> to reopen the topic because there are other possibilities which may cause
>> the possibility of failure after form validation to become real, especially
>> if network connection is involved.
>>
>>
>> I suggest Django should provide mechanism which allow handling the
>> unexpected failures after form validation, e.g. expect `ValidationError` to
>> be raised by `ModelAdmin.save_model`.
>>
>>
>> I started this discussion as a result of wontfix from
>> https://code.djangoproject.com/ticket/25777.
>>
>>
>> Vlastik
>>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/1db10ddc-eae6-4f17-a596-b8ce1aa8ef1f%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANJp-yh7HTnVowJx08VVU2dqAk9pSVnd%2B40XXdSeeYnG8LSLbA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: annoyance with Python 3.2 support in Django 1.8

2015-11-25 Thread Asif Saifuddin
Python 3.2 should be removed as if any one use py3 should use 3.3+ or 
better the latest stable.

best

Asif

On Thursday, November 26, 2015 at 6:36:53 AM UTC+6, Tim Graham wrote:
>
> Django 1.8 is the last version to support Python 3.2. Python 3.2 is 
> scheduled to be end of life at February 2016 [1] while Django 1.8 is 
> scheduled to be supported until April 2018. The latest security release for 
> the 3.2 series, Python 3.2.6 contained a regression that causes 30 admin 
> test failures in the Django test suite related to parsing of httponly 
> cookies. I'm not sure if this problem is limited to the test client or if 
> it has the potential to cause problems in a web server context (if anyone 
> is using Python 3.2.6, I'd be interested to know). I submitted a patch to 
> Python to correct the issue [2], but it appears unlikely that the patch 
> will be applied along with a new release (no response from Python 3.2 
> release manager in 1 year).
>
> Due to the test failures, we cannot run the Django test suite with Python 
> 3.2 on the Ubuntu 14.04 CI machines which use the deadsnakes PPA [3] to 
> install the latest version of Python (3.2.6). Therefore the tests are 
> limited to running on our one remaining Ubuntu 12.04 CI machine which 
> includes Python 3.2.3 (deadsnakes doesn't bundle versions of Python that 
> would override the one included by the distribution). Support for Ubuntu 
> 12.04 ends April 2017, so we shouldn't keep that machine longer than that.
>
> Options:
> 1. Drop Python 3.2 support for Django 1.8 sometime before Django 1.8 EOL
> 2. Keep Python 3.2 support until Django 1.8 EOL:
>   a. Don't worry about CI support and rely on local testing of security 
> fixes (we had the same situation with Django 1.4 and Python 2.5)
>   b. Install the latest non-broken Python 3.2 release (3.2.5) "manually" 
> (without using deadsnakes) on the newer CI servers
> 3. Your idea
>
> Thanks for your feedback!
>
> [1] https://www.python.org/dev/peps/pep-0392/
> [2] https://bugs.python.org/issue22758
> [3] https://launchpad.net/~fkrull/+archive/ubuntu/deadsnakes
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/bfc650af-6c28-4bc3-b792-5ae212accdb4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


annoyance with Python 3.2 support in Django 1.8

2015-11-25 Thread Tim Graham
Django 1.8 is the last version to support Python 3.2. Python 3.2 is 
scheduled to be end of life at February 2016 [1] while Django 1.8 is 
scheduled to be supported until April 2018. The latest security release for 
the 3.2 series, Python 3.2.6 contained a regression that causes 30 admin 
test failures in the Django test suite related to parsing of httponly 
cookies. I'm not sure if this problem is limited to the test client or if 
it has the potential to cause problems in a web server context (if anyone 
is using Python 3.2.6, I'd be interested to know). I submitted a patch to 
Python to correct the issue [2], but it appears unlikely that the patch 
will be applied along with a new release (no response from Python 3.2 
release manager in 1 year).

Due to the test failures, we cannot run the Django test suite with Python 
3.2 on the Ubuntu 14.04 CI machines which use the deadsnakes PPA [3] to 
install the latest version of Python (3.2.6). Therefore the tests are 
limited to running on our one remaining Ubuntu 12.04 CI machine which 
includes Python 3.2.3 (deadsnakes doesn't bundle versions of Python that 
would override the one included by the distribution). Support for Ubuntu 
12.04 ends April 2017, so we shouldn't keep that machine longer than that.

Options:
1. Drop Python 3.2 support for Django 1.8 sometime before Django 1.8 EOL
2. Keep Python 3.2 support until Django 1.8 EOL:
  a. Don't worry about CI support and rely on local testing of security 
fixes (we had the same situation with Django 1.4 and Python 2.5)
  b. Install the latest non-broken Python 3.2 release (3.2.5) "manually" 
(without using deadsnakes) on the newer CI servers
3. Your idea

Thanks for your feedback!

[1] https://www.python.org/dev/peps/pep-0392/
[2] https://bugs.python.org/issue22758
[3] https://launchpad.net/~fkrull/+archive/ubuntu/deadsnakes

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/34dd15c4-dba5-46fe-9ac0-6d5a426db2df%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Add an optional parameter to values() that returns a nested dictionary for foreign keys

2015-11-25 Thread Josh Smeaton
I would really like two things for values to support.

1. Aliases .values(alias='field');
2. Expressions .values(alias=F('field'))

I think these two features are absolute must haves, and the syntaxes above 
are already standard in other parts of the ORM.

If someone can come up with a way to support nested relations while 
supporting the above syntax, then I'd be OK with that. But at the moment, 
I'm firmly in the "this is the responsibility of a serialiser" camp. I'm 
not convinced Django needs to support nested objects at all. Is this 
something you could implement with your own queryset method on a manager? 
Is this maybe something we could look at creating a new queryset method 
called .values_dict() ?

If it weren't for backwards compatibility, I'd suggest that referencing the 
related object would automatically nest that object. That would 
differentiate between the id and the field values('related_id', 'related') 
-> '{"related_id": 1, "related": {"id": 1, ..}}'.

If there's (rough) consensus on having nested objects, then we could allow 
something like: .values(..., ..., nested=('related', 
'related__otherrelated')). If the value of nested is an iterable then 
assume we're nesting, otherwise nested is an alias for the field. I don't 
particularly like overloaded kwargs, but we're just guarding against 
someone wanting to alias as "nested" which we could call out in docs anyway.

The more I think about this the more I think nesting and aliases within a 
nest should probably be done in a different queryset method. Or just 
handled by a serialiser. If you want more requests per second, then add 
some more backends.

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/35310a81-737b-43e1-b034-94d68f9ffd0f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Add an optional parameter to values() that returns a nested dictionary for foreign keys

2015-11-25 Thread Shai Berger
On Wednesday 25 November 2015 20:34:11 Marc Tamlyn wrote:
> I can see a use for this, but the API is unsure. Given that from a
> performance point of view it should be possible to do this as a transform
> after a values query (in most cases using a similar lazy sequence-like
> object will maintain the performance you need), can I propose implementing
> it as an external app to find a good API. Once this has been done, we can
> look at how buildable that API is at a lower level to get the maximum
> performance.
> 

That sounds like a good plan to me.

I would just like to add that, since we're talking about values() queries 
where no model instances are constructed, one possible API is to have just a 
single boolean `nested` argument, where the selection of which FKs to expand 
is implied by select_related() calls.

Shai.


Re: Allow impossible model validation (mainly admin and generic forms)

2015-11-25 Thread Tim Graham
Would Django itself ever raise ValidationError in Model.save()?

I wonder how you propose converting something like an IntegrityError from 
the database into an "friendly" exception for the user?

On Wednesday, November 25, 2015 at 9:23:05 AM UTC-5, Vlastimil Zíma wrote:
>
> Django assumes that all input data in forms can be validated by 
> `Form.is_valid()` which in some cases is not true. Database contraints, 
> e.g. unique, can fail even though they are checked. An application may 
> require communication with other servers while processing data which can 
> lead to errors. But these conditions are not expected by regular Django 
> form flow and an attempt to handle these cases results in large overriding 
> of default implementation.
>
>
> This topic was previously discussed here 
> https://groups.google.com/d/topic/django-developers/rzjpP0byNQo/discussion, 
> but discussion was mainly based on race condition in unique check. I'd like 
> to reopen the topic because there are other possibilities which may cause 
> the possibility of failure after form validation to become real, especially 
> if network connection is involved.
>
>
> I suggest Django should provide mechanism which allow handling the 
> unexpected failures after form validation, e.g. expect `ValidationError` to 
> be raised by `ModelAdmin.save_model`.
>
>
> I started this discussion as a result of wontfix from 
> https://code.djangoproject.com/ticket/25777.
>
>
> Vlastik
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1db10ddc-eae6-4f17-a596-b8ce1aa8ef1f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Add an optional parameter to values() that returns a nested dictionary for foreign keys

2015-11-25 Thread Marc Tamlyn
I can see a use for this, but the API is unsure. Given that from a
performance point of view it should be possible to do this as a transform
after a values query (in most cases using a similar lazy sequence-like
object will maintain the performance you need), can I propose implementing
it as an external app to find a good API. Once this has been done, we can
look at how buildable that API is at a lower level to get the maximum
performance.

On 25 November 2015 at 18:21, Moenad  wrote:

> I think I wasn't clear from the beginning, the idea of "nested" is to nest
> all possible levels, not just a single level. I like the idea of "N", given
> that you can have more control, but having something like N("person",
> "person__hometown", "person__hometown__country") which will be different
> than N("person__hometown__country") is confusing.
>
> I have another idea, why not make the alias + nest possible with a single
> parameter, where it takes a dictionary and expect how the final structure
> and aliasing are?
>
> For example:
>
> {"id": "custom_id"
>  "first_name": "custom_first_name",
>  "last_name": "custom_last_name",
>  "hometown": {
>   "__alias__": "custom_hometown"
>   "id": "custom_hometown_id",
>   "name": "custom_name",
>   "country": "custom_country"
>   }
> }
>
> or to make it a standard in someway,
>
> {"id": "custom_id"
>  "first_name": "custom_first_name",
>  "last_name": "custom_last_name",
>  "hometown": {
>   "__alias__": "custom_hometown"
>   "hometown__id": "custom_hometown_id",
>   "hometown__name": "custom_name",
>   "hometown__country": "custom_country"
>   }
> }
>
> as you noticed, if there's a foreign key for example, a new key
> "__alias__" or something should be added in the dict. Also, no need for
> values() *args, the dict structure would be more than enough?
>
>
> On Wednesday, November 25, 2015 at 7:21:43 PM UTC+2, Joachim Jablon wrote:
>>
>> Marten's suggestion is quite interesting for providing a way to tell
>> which data you want nested and which data you don't. Plus, this form
>> might be interesting to solve another problem : how would Django know if we
>> want :
>>
>> {"id": 1
>>  "first_name": "first name",
>>  "last_name": "last name",
>>  "hometown": {
>>   "id": 1,
>>   "name": "town name",
>>   "country": 3
>>   }
>> }
>>
>>
>> # or
>>
>>
>> {"id": 1
>>  "first_name": "first name",
>>  "last_name": "last name",
>>  "hometown": {
>>   "id": 1,
>>   "name": "town name",
>>   "country": {
>> "id": 3,
>> "name": "country name"
>>   }
>>   }
>> }
>>
>>
>>
>> Limiting the nesting to a single level would be an arbitrary decision and
>> users should be able to control this (IMHO)
>>
>> So we could have a "level" argument that would say how many levels deep
>> it will search but then what if you want SOME nesting in some branches, not
>> in others, like :
>>
>> {"id": 1
>>  "first_name": "first name",
>>  "last_name": "last name",
>>  "hometown": {
>>   "id": 1,
>>   "name": "town name",
>>   "country": {
>> "id": 3,
>> "name": "country name"
>>   }
>>   },
>>   "father": 4
>> }
>>
>>
>> (here, "father" is another FK that we don't want expanded ?
>>
>> Maybe a syntax like :
>>
>> N("person", "person__hometown", "person__hometown__country")
>> Note : this might not be equivalent to N("person__hometown__country"),
>> that you could use if you want ONLY the nested "country"
>>
>> I'd like that.
>>
>> And it's compatible with the suggestion of using **kwargs for aliasing
>> (for the top level element of the dict, at least)
>>
>> Le mercredi 25 novembre 2015 17:53:25 UTC+1, Marten Kenbeek a écrit :
>>>
>>> I think it'd be more consistent with other parts of the ORM to use
>>> **kwargs to specify aliases. For nested data you can use an object, say N,
>>> similar to Q and F objects:
>>>
>>> Articles.objects.filter(id=1).values('body', N('author'),
>>> my_custom_title='title')
>>>
>>> I'm no ORM expert, but could something like this be possible by allowing
>>> expressions in values() and using custom output fields?
>>>
>>> On Wednesday, November 25, 2015 at 5:09:29 PM UTC+1, Moenad wrote:

 Well, switch the field name aliasing to a dictionary without hijacking
 **kwargs ?

 I prefer the following:

 Articles.objects.get(id=1).values(’title’, ’author’, ‘body',
 alias={"title": "my_custom_title"}, nested=True)


 On Wednesday, November 25, 2015 at 5:43:51 PM UTC+2, Tim Graham wrote:
>
> There's an accepted ticket for adding aliasing to values():
> https://code.djangoproject.com/ticket/16735
>
> The current patch there hijacks values() **kwargs for the mapping of
> renamed fields which would prevent adding other kwargs like "nested"
> without disallowing those values as aliases. I guess we may want to 
> rethink
> that approach.
>
> On Wednesday, November 25, 2015 at 10:20:37 

Re: Add an optional parameter to values() that returns a nested dictionary for foreign keys

2015-11-25 Thread Moenad
I think I wasn't clear from the beginning, the idea of "nested" is to nest 
all possible levels, not just a single level. I like the idea of "N", given 
that you can have more control, but having something like N("person", 
"person__hometown", "person__hometown__country") which will be different 
than N("person__hometown__country") is confusing.

I have another idea, why not make the alias + nest possible with a single 
parameter, where it takes a dictionary and expect how the final structure 
and aliasing are?

For example:

{"id": "custom_id"
 "first_name": "custom_first_name",
 "last_name": "custom_last_name",
 "hometown": {
  "__alias__": "custom_hometown"
  "id": "custom_hometown_id",
  "name": "custom_name",
  "country": "custom_country"
  }
}

or to make it a standard in someway,

{"id": "custom_id"
 "first_name": "custom_first_name",
 "last_name": "custom_last_name",
 "hometown": {
  "__alias__": "custom_hometown"
  "hometown__id": "custom_hometown_id",
  "hometown__name": "custom_name",
  "hometown__country": "custom_country"
  }
}

as you noticed, if there's a foreign key for example, a new key "__alias__" 
or something should be added in the dict. Also, no need for values() *args, 
the dict structure would be more than enough?


On Wednesday, November 25, 2015 at 7:21:43 PM UTC+2, Joachim Jablon wrote:
>
> Marten's suggestion is quite interesting for providing a way to tell which 
> data you want nested and which data you don't. Plus, this form might be 
> interesting to solve another problem : how would Django know if we want :
>
> {"id": 1
>  "first_name": "first name",
>  "last_name": "last name",
>  "hometown": {
>   "id": 1,
>   "name": "town name",
>   "country": 3
>   }
> }
>
>
> # or
>
>
> {"id": 1
>  "first_name": "first name",
>  "last_name": "last name",
>  "hometown": {
>   "id": 1,
>   "name": "town name",
>   "country": {
> "id": 3,
> "name": "country name"
>   }
>   }
> }
>
>
>
> Limiting the nesting to a single level would be an arbitrary decision and 
> users should be able to control this (IMHO)
>
> So we could have a "level" argument that would say how many levels deep it 
> will search but then what if you want SOME nesting in some branches, not in 
> others, like : 
>
> {"id": 1
>  "first_name": "first name",
>  "last_name": "last name",
>  "hometown": {
>   "id": 1,
>   "name": "town name",
>   "country": {
> "id": 3,
> "name": "country name"
>   }
>   },
>   "father": 4
> }
>
>
> (here, "father" is another FK that we don't want expanded ?
>
> Maybe a syntax like :
>
> N("person", "person__hometown", "person__hometown__country")
> Note : this might not be equivalent to N("person__hometown__country"), 
> that you could use if you want ONLY the nested "country"
>
> I'd like that.
>
> And it's compatible with the suggestion of using **kwargs for aliasing 
> (for the top level element of the dict, at least)
>
> Le mercredi 25 novembre 2015 17:53:25 UTC+1, Marten Kenbeek a écrit :
>>
>> I think it'd be more consistent with other parts of the ORM to use 
>> **kwargs to specify aliases. For nested data you can use an object, say N, 
>> similar to Q and F objects:
>>
>> Articles.objects.filter(id=1).values('body', N('author'), my_custom_title
>> ='title')
>>
>> I'm no ORM expert, but could something like this be possible by allowing 
>> expressions in values() and using custom output fields?
>>
>> On Wednesday, November 25, 2015 at 5:09:29 PM UTC+1, Moenad wrote:
>>>
>>> Well, switch the field name aliasing to a dictionary without hijacking 
>>> **kwargs ?
>>>
>>> I prefer the following:
>>>
>>> Articles.objects.get(id=1).values(’title’, ’author’, ‘body', 
>>> alias={"title": "my_custom_title"}, nested=True)
>>>
>>>
>>> On Wednesday, November 25, 2015 at 5:43:51 PM UTC+2, Tim Graham wrote:

 There's an accepted ticket for adding aliasing to values(): 
 https://code.djangoproject.com/ticket/16735

 The current patch there hijacks values() **kwargs for the mapping of 
 renamed fields which would prevent adding other kwargs like "nested" 
 without disallowing those values as aliases. I guess we may want to 
 rethink 
 that approach.

 On Wednesday, November 25, 2015 at 10:20:37 AM UTC-5, Bobby Mozumder 
 wrote:
>
> I could also use a couple of enhancement to this:
>
> 1) Allow renaming of keys, instead of using the database column names. 
>  
> 2) Allow callbacks functions (or lambdas) to convert output values to 
> another format if needed.
>
> With this, I could send the queries results right to JSON outputs.
>
> -bobby
>
> On Nov 25, 2015, at 9:05 AM, Moenad  wrote:
>
> Currently, after calling values() and the query executes, the output 
> is a single level dictionary, including foreign keys. I propose adding an 
> extra parameter for 

Re: Keep django/django-old GitHub repo?

2015-11-25 Thread Jannis Leidel

> On 25 Nov 2015, at 18:50, Aymeric Augustin 
>  wrote:
> 
> The real question is — did anyone remember that it existed before Tim brought 
> it up? I’m pretty sure we can drop it.

Sure I remember, I have still a bunch of branches in my local clone from repo 
that I hope to get back to eventually. Just kidding, I think when we did the 
real conversion we didn’t loose any branches or commits, so that mirror is only 
left there for historical reasons. Let’s hope nobody deploys from it.

> (For the more recent community members, it’s a git mirror of the original svn 
> repo that predated the conversion of the official repo to git. We kept it 
> around when we migrated.)
> 
> -- 
> Aymeric.
> 
> 
> 
>> On 25 nov. 2015, at 16:16, Marc Tamlyn  wrote:
>> 
>> As there are no active PRs there any more I'm pretty sure it can be ditched.
>> 
>> On 25 November 2015 at 14:36, Tim Graham  wrote:
>> Does https://github.com/django/django-old provide any value? I think it can 
>> be deleted. Maybe there are a few links to the pull requests there but I've 
>> never come across any.
>> 
>> -- 
>> 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 http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/cefde00b-f822-45e4-a706-18273a236975%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 http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/CAMwjO1HNX8rO9KkFpe62Hb%3DV8SijHLBmNpBi2q3XC6%2BtL0Fsmw%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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/463BDBC3-02F1-43AC-A9F5-E3DFD02C65F1%40polytechnique.org.
> 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/477FE5AD-6890-475D-B1E3-0C02DF6E37F7%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Keep django/django-old GitHub repo?

2015-11-25 Thread Aymeric Augustin
The real question is — did anyone remember that it existed before Tim brought 
it up? I’m pretty sure we can drop it.

(For the more recent community members, it’s a git mirror of the original svn 
repo that predated the conversion of the official repo to git. We kept it 
around when we migrated.)

-- 
Aymeric.



> On 25 nov. 2015, at 16:16, Marc Tamlyn  wrote:
> 
> As there are no active PRs there any more I'm pretty sure it can be ditched.
> 
> On 25 November 2015 at 14:36, Tim Graham  > wrote:
> Does https://github.com/django/django-old 
>  provide any value? I think it can be 
> deleted. Maybe there are a few links to the pull requests there but I've 
> never come across any.
> 
> -- 
> 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 http://groups.google.com/group/django-developers 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/cefde00b-f822-45e4-a706-18273a236975%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 http://groups.google.com/group/django-developers 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CAMwjO1HNX8rO9KkFpe62Hb%3DV8SijHLBmNpBi2q3XC6%2BtL0Fsmw%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/463BDBC3-02F1-43AC-A9F5-E3DFD02C65F1%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.


Re: Add an optional parameter to values() that returns a nested dictionary for foreign keys

2015-11-25 Thread Joachim Jablon
Marten's suggestion is quite interesting for providing a way to tell which 
data you want nested and which data you don't. Plus, this form might be 
interesting to solve another problem : how would Django know if we want :

{"id": 1
 "first_name": "first name",
 "last_name": "last name",
 "hometown": {
  "id": 1,
  "name": "town name",
  "country": 3
  }
}


# or


{"id": 1
 "first_name": "first name",
 "last_name": "last name",
 "hometown": {
  "id": 1,
  "name": "town name",
  "country": {
"id": 3,
"name": "country name"
  }
  }
}



Limiting the nesting to a single level would be an arbitrary decision and 
users should be able to control this (IMHO)

So we could have a "level" argument that would say how many levels deep it 
will search but then what if you want SOME nesting in some branches, not in 
others, like : 

{"id": 1
 "first_name": "first name",
 "last_name": "last name",
 "hometown": {
  "id": 1,
  "name": "town name",
  "country": {
"id": 3,
"name": "country name"
  }
  },
  "father": 4
}


(here, "father" is another FK that we don't want expanded ?

Maybe a syntax like :

N("person", "person__hometown", "person__hometown__country")
Note : this might not be equivalent to N("person__hometown__country"), that 
you could use if you want ONLY the nested "country"

I'd like that.

And it's compatible with the suggestion of using **kwargs for aliasing (for 
the top level element of the dict, at least)

Le mercredi 25 novembre 2015 17:53:25 UTC+1, Marten Kenbeek a écrit :
>
> I think it'd be more consistent with other parts of the ORM to use 
> **kwargs to specify aliases. For nested data you can use an object, say N, 
> similar to Q and F objects:
>
> Articles.objects.filter(id=1).values('body', N('author'), my_custom_title=
> 'title')
>
> I'm no ORM expert, but could something like this be possible by allowing 
> expressions in values() and using custom output fields?
>
> On Wednesday, November 25, 2015 at 5:09:29 PM UTC+1, Moenad wrote:
>>
>> Well, switch the field name aliasing to a dictionary without hijacking 
>> **kwargs ?
>>
>> I prefer the following:
>>
>> Articles.objects.get(id=1).values(’title’, ’author’, ‘body', 
>> alias={"title": "my_custom_title"}, nested=True)
>>
>>
>> On Wednesday, November 25, 2015 at 5:43:51 PM UTC+2, Tim Graham wrote:
>>>
>>> There's an accepted ticket for adding aliasing to values(): 
>>> https://code.djangoproject.com/ticket/16735
>>>
>>> The current patch there hijacks values() **kwargs for the mapping of 
>>> renamed fields which would prevent adding other kwargs like "nested" 
>>> without disallowing those values as aliases. I guess we may want to rethink 
>>> that approach.
>>>
>>> On Wednesday, November 25, 2015 at 10:20:37 AM UTC-5, Bobby Mozumder 
>>> wrote:

 I could also use a couple of enhancement to this:

 1) Allow renaming of keys, instead of using the database column names.  
 2) Allow callbacks functions (or lambdas) to convert output values to 
 another format if needed.

 With this, I could send the queries results right to JSON outputs.

 -bobby

 On Nov 25, 2015, at 9:05 AM, Moenad  wrote:

 Currently, after calling values() and the query executes, the output is 
 a single level dictionary, including foreign keys. I propose adding an 
 extra parameter for values, or at least values_list, where if it's set to 
 true, a nested dictionary will be returned when there's a foreign key.

 Example:

 Person model with the following fields: first_name, last_name and 
 hometown (foreign key)
 Hometown model with the following fields: name

 A single record from Person.objects.values() will looks like this

 {"id": 1
  "first_name": "first name",
  "last_name": "last name",
  "hometown__id": 1,
  "hometown__name": "town name",
 }


 I propose adding a nested optional parameter to values, where a single 
 record from Person.objects.values(nested=True) will look like

 {"id": 1
  "first_name": "first name",
  "last_name": "last name",
  "hometown": {
   "id": 1,
   "name": "town name"
   }
 }


 This feature is needed given that most APIs these days are nested, 
 while it's simple to implement, I think it's much better to have it a 
 built-in django feature.


 -- 
 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-develop...@googlegroups.com.
 To post to this group, send email to django-d...@googlegroups.com.
 Visit this group at http://groups.google.com/group/django-developers.
 To view this discussion on the web visit 
 

Re: Add an optional parameter to values() that returns a nested dictionary for foreign keys

2015-11-25 Thread Moenad
I like the idea but what about multiple nesting, multiple foreign keys?

We end up with something like N('author__book')? a bit confusing no?

On Wednesday, November 25, 2015 at 6:53:25 PM UTC+2, Marten Kenbeek wrote:
>
> I think it'd be more consistent with other parts of the ORM to use 
> **kwargs to specify aliases. For nested data you can use an object, say N, 
> similar to Q and F objects:
>
> Articles.objects.filter(id=1).values('body', N('author'), my_custom_title=
> 'title')
>
> I'm no ORM expert, but could something like this be possible by allowing 
> expressions in values() and using custom output fields?
>
> On Wednesday, November 25, 2015 at 5:09:29 PM UTC+1, Moenad wrote:
>>
>> Well, switch the field name aliasing to a dictionary without hijacking 
>> **kwargs ?
>>
>> I prefer the following:
>>
>> Articles.objects.get(id=1).values(’title’, ’author’, ‘body', 
>> alias={"title": "my_custom_title"}, nested=True)
>>
>>
>> On Wednesday, November 25, 2015 at 5:43:51 PM UTC+2, Tim Graham wrote:
>>>
>>> There's an accepted ticket for adding aliasing to values(): 
>>> https://code.djangoproject.com/ticket/16735
>>>
>>> The current patch there hijacks values() **kwargs for the mapping of 
>>> renamed fields which would prevent adding other kwargs like "nested" 
>>> without disallowing those values as aliases. I guess we may want to rethink 
>>> that approach.
>>>
>>> On Wednesday, November 25, 2015 at 10:20:37 AM UTC-5, Bobby Mozumder 
>>> wrote:

 I could also use a couple of enhancement to this:

 1) Allow renaming of keys, instead of using the database column names.  
 2) Allow callbacks functions (or lambdas) to convert output values to 
 another format if needed.

 With this, I could send the queries results right to JSON outputs.

 -bobby

 On Nov 25, 2015, at 9:05 AM, Moenad  wrote:

 Currently, after calling values() and the query executes, the output is 
 a single level dictionary, including foreign keys. I propose adding an 
 extra parameter for values, or at least values_list, where if it's set to 
 true, a nested dictionary will be returned when there's a foreign key.

 Example:

 Person model with the following fields: first_name, last_name and 
 hometown (foreign key)
 Hometown model with the following fields: name

 A single record from Person.objects.values() will looks like this

 {"id": 1
  "first_name": "first name",
  "last_name": "last name",
  "hometown__id": 1,
  "hometown__name": "town name",
 }


 I propose adding a nested optional parameter to values, where a single 
 record from Person.objects.values(nested=True) will look like

 {"id": 1
  "first_name": "first name",
  "last_name": "last name",
  "hometown": {
   "id": 1,
   "name": "town name"
   }
 }


 This feature is needed given that most APIs these days are nested, 
 while it's simple to implement, I think it's much better to have it a 
 built-in django feature.


 -- 
 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-develop...@googlegroups.com.
 To post to this group, send email to django-d...@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/8e5cbc9a-0317-40d3-8038-5b4300738b90%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1b790e4a-4767-443d-bc09-35f4ead19821%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Add an optional parameter to values() that returns a nested dictionary for foreign keys

2015-11-25 Thread Marten Kenbeek
I think it'd be more consistent with other parts of the ORM to use **kwargs 
to specify aliases. For nested data you can use an object, say N, similar 
to Q and F objects:

Articles.objects.filter(id=1).values('body', N('author'), my_custom_title=
'title')

I'm no ORM expert, but could something like this be possible by allowing 
expressions in values() and using custom output fields?

On Wednesday, November 25, 2015 at 5:09:29 PM UTC+1, Moenad wrote:
>
> Well, switch the field name aliasing to a dictionary without hijacking 
> **kwargs ?
>
> I prefer the following:
>
> Articles.objects.get(id=1).values(’title’, ’author’, ‘body', 
> alias={"title": "my_custom_title"}, nested=True)
>
>
> On Wednesday, November 25, 2015 at 5:43:51 PM UTC+2, Tim Graham wrote:
>>
>> There's an accepted ticket for adding aliasing to values(): 
>> https://code.djangoproject.com/ticket/16735
>>
>> The current patch there hijacks values() **kwargs for the mapping of 
>> renamed fields which would prevent adding other kwargs like "nested" 
>> without disallowing those values as aliases. I guess we may want to rethink 
>> that approach.
>>
>> On Wednesday, November 25, 2015 at 10:20:37 AM UTC-5, Bobby Mozumder 
>> wrote:
>>>
>>> I could also use a couple of enhancement to this:
>>>
>>> 1) Allow renaming of keys, instead of using the database column names.  
>>> 2) Allow callbacks functions (or lambdas) to convert output values to 
>>> another format if needed.
>>>
>>> With this, I could send the queries results right to JSON outputs.
>>>
>>> -bobby
>>>
>>> On Nov 25, 2015, at 9:05 AM, Moenad  wrote:
>>>
>>> Currently, after calling values() and the query executes, the output is 
>>> a single level dictionary, including foreign keys. I propose adding an 
>>> extra parameter for values, or at least values_list, where if it's set to 
>>> true, a nested dictionary will be returned when there's a foreign key.
>>>
>>> Example:
>>>
>>> Person model with the following fields: first_name, last_name and 
>>> hometown (foreign key)
>>> Hometown model with the following fields: name
>>>
>>> A single record from Person.objects.values() will looks like this
>>>
>>> {"id": 1
>>>  "first_name": "first name",
>>>  "last_name": "last name",
>>>  "hometown__id": 1,
>>>  "hometown__name": "town name",
>>> }
>>>
>>>
>>> I propose adding a nested optional parameter to values, where a single 
>>> record from Person.objects.values(nested=True) will look like
>>>
>>> {"id": 1
>>>  "first_name": "first name",
>>>  "last_name": "last name",
>>>  "hometown": {
>>>   "id": 1,
>>>   "name": "town name"
>>>   }
>>> }
>>>
>>>
>>> This feature is needed given that most APIs these days are nested, while 
>>> it's simple to implement, I think it's much better to have it a built-in 
>>> django feature.
>>>
>>>
>>> -- 
>>> 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-develop...@googlegroups.com.
>>> To post to this group, send email to django-d...@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/8e5cbc9a-0317-40d3-8038-5b4300738b90%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/32061525-207b-4dd7-99d9-45e2fa19ad9d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Add an optional parameter to values() that returns a nested dictionary for foreign keys

2015-11-25 Thread Moenad
Well, switch the field name aliasing to a dictionary without hijacking 
**kwargs ?

I prefer the following:

Articles.objects.get(id=1).values(’title’, ’author’, ‘body', 
alias={"title": "my_custom_title"}, nested=True)


On Wednesday, November 25, 2015 at 5:43:51 PM UTC+2, Tim Graham wrote:
>
> There's an accepted ticket for adding aliasing to values(): 
> https://code.djangoproject.com/ticket/16735
>
> The current patch there hijacks values() **kwargs for the mapping of 
> renamed fields which would prevent adding other kwargs like "nested" 
> without disallowing those values as aliases. I guess we may want to rethink 
> that approach.
>
> On Wednesday, November 25, 2015 at 10:20:37 AM UTC-5, Bobby Mozumder wrote:
>>
>> I could also use a couple of enhancement to this:
>>
>> 1) Allow renaming of keys, instead of using the database column names.  
>> 2) Allow callbacks functions (or lambdas) to convert output values to 
>> another format if needed.
>>
>> With this, I could send the queries results right to JSON outputs.
>>
>> -bobby
>>
>> On Nov 25, 2015, at 9:05 AM, Moenad  wrote:
>>
>> Currently, after calling values() and the query executes, the output is a 
>> single level dictionary, including foreign keys. I propose adding an extra 
>> parameter for values, or at least values_list, where if it's set to true, a 
>> nested dictionary will be returned when there's a foreign key.
>>
>> Example:
>>
>> Person model with the following fields: first_name, last_name and 
>> hometown (foreign key)
>> Hometown model with the following fields: name
>>
>> A single record from Person.objects.values() will looks like this
>>
>> {"id": 1
>>  "first_name": "first name",
>>  "last_name": "last name",
>>  "hometown__id": 1,
>>  "hometown__name": "town name",
>> }
>>
>>
>> I propose adding a nested optional parameter to values, where a single 
>> record from Person.objects.values(nested=True) will look like
>>
>> {"id": 1
>>  "first_name": "first name",
>>  "last_name": "last name",
>>  "hometown": {
>>   "id": 1,
>>   "name": "town name"
>>   }
>> }
>>
>>
>> This feature is needed given that most APIs these days are nested, while 
>> it's simple to implement, I think it's much better to have it a built-in 
>> django feature.
>>
>>
>> -- 
>> 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-develop...@googlegroups.com.
>> To post to this group, send email to django-d...@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/8e5cbc9a-0317-40d3-8038-5b4300738b90%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/22edbb32-ff5c-4b1c-be9b-516d74014d4b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Add an optional parameter to values() that returns a nested dictionary for foreign keys

2015-11-25 Thread Bobby Mozumder
A useful overall target for the next Django version would be to try and get all 
these feature up so that high-speed REST API development becomes easier.  
(really need to be able to push thousands of requests per second)

I’d like to directly go from Query to Response:  

response = JsonResponse(Articles.objects.get(id=1).values(’title’, ’author’, 
‘body'))   

While still having things like aliased fields, nested trees, and value 
formatting.

-bobby

> On Nov 25, 2015, at 10:43 AM, Tim Graham  wrote:
> 
> There's an accepted ticket for adding aliasing to values(): 
> https://code.djangoproject.com/ticket/16735
> 
> The current patch there hijacks values() **kwargs for the mapping of renamed 
> fields which would prevent adding other kwargs like "nested" without 
> disallowing those values as aliases. I guess we may want to rethink that 
> approach.
> 
> On Wednesday, November 25, 2015 at 10:20:37 AM UTC-5, Bobby Mozumder wrote:
> I could also use a couple of enhancement to this:
> 
> 1) Allow renaming of keys, instead of using the database column names.  
> 2) Allow callbacks functions (or lambdas) to convert output values to another 
> format if needed.
> 
> With this, I could send the queries results right to JSON outputs.
> 
> -bobby
> 
>> On Nov 25, 2015, at 9:05 AM, Moenad  wrote:
>> 
>> Currently, after calling values() and the query executes, the output is a 
>> single level dictionary, including foreign keys. I propose adding an extra 
>> parameter for values, or at least values_list, where if it's set to true, a 
>> nested dictionary will be returned when there's a foreign key.
>> 
>> Example:
>> 
>> Person model with the following fields: first_name, last_name and hometown 
>> (foreign key)
>> Hometown model with the following fields: name
>> 
>> A single record from Person.objects.values() will looks like this
>> 
>> {"id": 1
>>  "first_name": "first name",
>>  "last_name": "last name",
>>  "hometown__id": 1,
>>  "hometown__name": "town name",
>> }
>> 
>> 
>> I propose adding a nested optional parameter to values, where a single 
>> record from Person.objects.values(nested=True) will look like
>> 
>> {"id": 1
>>  "first_name": "first name",
>>  "last_name": "last name",
>>  "hometown": {
>>   "id": 1,
>>   "name": "town name"
>>   }
>> }
>> 
>> 
>> This feature is needed given that most APIs these days are nested, while 
>> it's simple to implement, I think it's much better to have it a built-in 
>> django feature.
>> 
>> 
>> -- 
>> 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-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@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/8e5cbc9a-0317-40d3-8038-5b4300738b90%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 http://groups.google.com/group/django-developers 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/369843ca-7b82-49b9-b7f5-e2f7fa578ca7%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/12798868-66C3-4449-837B-B54E259CFF24%40gmail.com.
For more options, 

Re: Add an optional parameter to values() that returns a nested dictionary for foreign keys

2015-11-25 Thread Tim Graham
There's an accepted ticket for adding aliasing to values(): 
https://code.djangoproject.com/ticket/16735

The current patch there hijacks values() **kwargs for the mapping of 
renamed fields which would prevent adding other kwargs like "nested" 
without disallowing those values as aliases. I guess we may want to rethink 
that approach.

On Wednesday, November 25, 2015 at 10:20:37 AM UTC-5, Bobby Mozumder wrote:
>
> I could also use a couple of enhancement to this:
>
> 1) Allow renaming of keys, instead of using the database column names.  
> 2) Allow callbacks functions (or lambdas) to convert output values to 
> another format if needed.
>
> With this, I could send the queries results right to JSON outputs.
>
> -bobby
>
> On Nov 25, 2015, at 9:05 AM, Moenad  
> wrote:
>
> Currently, after calling values() and the query executes, the output is a 
> single level dictionary, including foreign keys. I propose adding an extra 
> parameter for values, or at least values_list, where if it's set to true, a 
> nested dictionary will be returned when there's a foreign key.
>
> Example:
>
> Person model with the following fields: first_name, last_name and hometown 
> (foreign key)
> Hometown model with the following fields: name
>
> A single record from Person.objects.values() will looks like this
>
> {"id": 1
>  "first_name": "first name",
>  "last_name": "last name",
>  "hometown__id": 1,
>  "hometown__name": "town name",
> }
>
>
> I propose adding a nested optional parameter to values, where a single 
> record from Person.objects.values(nested=True) will look like
>
> {"id": 1
>  "first_name": "first name",
>  "last_name": "last name",
>  "hometown": {
>   "id": 1,
>   "name": "town name"
>   }
> }
>
>
> This feature is needed given that most APIs these days are nested, while 
> it's simple to implement, I think it's much better to have it a built-in 
> django feature.
>
>
> -- 
> 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-develop...@googlegroups.com .
> To post to this group, send email to django-d...@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/8e5cbc9a-0317-40d3-8038-5b4300738b90%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/369843ca-7b82-49b9-b7f5-e2f7fa578ca7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Add an optional parameter to values() that returns a nested dictionary for foreign keys

2015-11-25 Thread Moenad
100%, that would be great also. I thought of just posting the basic 
requirement that might be useful to most.

On Wednesday, November 25, 2015 at 5:20:37 PM UTC+2, Bobby Mozumder wrote:
>
> I could also use a couple of enhancement to this:
>
> 1) Allow renaming of keys, instead of using the database column names.  
> 2) Allow callbacks functions (or lambdas) to convert output values to 
> another format if needed.
>
> With this, I could send the queries results right to JSON outputs.
>
> -bobby
>
> On Nov 25, 2015, at 9:05 AM, Moenad  
> wrote:
>
> Currently, after calling values() and the query executes, the output is a 
> single level dictionary, including foreign keys. I propose adding an extra 
> parameter for values, or at least values_list, where if it's set to true, a 
> nested dictionary will be returned when there's a foreign key.
>
> Example:
>
> Person model with the following fields: first_name, last_name and hometown 
> (foreign key)
> Hometown model with the following fields: name
>
> A single record from Person.objects.values() will looks like this
>
> {"id": 1
>  "first_name": "first name",
>  "last_name": "last name",
>  "hometown__id": 1,
>  "hometown__name": "town name",
> }
>
>
> I propose adding a nested optional parameter to values, where a single 
> record from Person.objects.values(nested=True) will look like
>
> {"id": 1
>  "first_name": "first name",
>  "last_name": "last name",
>  "hometown": {
>   "id": 1,
>   "name": "town name"
>   }
> }
>
>
> This feature is needed given that most APIs these days are nested, while 
> it's simple to implement, I think it's much better to have it a built-in 
> django feature.
>
>
> -- 
> 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-develop...@googlegroups.com .
> To post to this group, send email to django-d...@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/8e5cbc9a-0317-40d3-8038-5b4300738b90%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/628187c5-3c83-40d4-9aeb-c3ee1bc10119%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Keep django/django-old GitHub repo?

2015-11-25 Thread Marc Tamlyn
As there are no active PRs there any more I'm pretty sure it can be ditched.

On 25 November 2015 at 14:36, Tim Graham  wrote:

> Does https://github.com/django/django-old provide any value? I think it
> can be deleted. Maybe there are a few links to the pull requests there but
> I've never come across any.
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/cefde00b-f822-45e4-a706-18273a236975%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1HNX8rO9KkFpe62Hb%3DV8SijHLBmNpBi2q3XC6%2BtL0Fsmw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Add an optional parameter to values() that returns a nested dictionary for foreign keys

2015-11-25 Thread Bobby Mozumder
I could also use a couple of enhancement to this:

1) Allow renaming of keys, instead of using the database column names.  
2) Allow callbacks functions (or lambdas) to convert output values to another 
format if needed.

With this, I could send the queries results right to JSON outputs.

-bobby

> On Nov 25, 2015, at 9:05 AM, Moenad  wrote:
> 
> Currently, after calling values() and the query executes, the output is a 
> single level dictionary, including foreign keys. I propose adding an extra 
> parameter for values, or at least values_list, where if it's set to true, a 
> nested dictionary will be returned when there's a foreign key.
> 
> Example:
> 
> Person model with the following fields: first_name, last_name and hometown 
> (foreign key)
> Hometown model with the following fields: name
> 
> A single record from Person.objects.values() will looks like this
> 
> {"id": 1
>  "first_name": "first name",
>  "last_name": "last name",
>  "hometown__id": 1,
>  "hometown__name": "town name",
> }
> 
> 
> I propose adding a nested optional parameter to values, where a single record 
> from Person.objects.values(nested=True) will look like
> 
> {"id": 1
>  "first_name": "first name",
>  "last_name": "last name",
>  "hometown": {
>   "id": 1,
>   "name": "town name"
>   }
> }
> 
> 
> This feature is needed given that most APIs these days are nested, while it's 
> simple to implement, I think it's much better to have it a built-in django 
> feature.
> 
> 
> -- 
> 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 http://groups.google.com/group/django-developers 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/8e5cbc9a-0317-40d3-8038-5b4300738b90%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2719FB24-E00F-4C85-BD9A-FF1FB2EB3799%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


Keep django/django-old GitHub repo?

2015-11-25 Thread Tim Graham
Does https://github.com/django/django-old provide any value? I think it can 
be deleted. Maybe there are a few links to the pull requests there but I've 
never come across any.

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/cefde00b-f822-45e4-a706-18273a236975%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Add an optional parameter to values() that returns a nested dictionary for foreign keys

2015-11-25 Thread Moenad
Currently, after calling values() and the query executes, the output is a 
single level dictionary, including foreign keys. I propose adding an extra 
parameter for values, or at least values_list, where if it's set to true, a 
nested dictionary will be returned when there's a foreign key.

Example:

Person model with the following fields: first_name, last_name and hometown 
(foreign key)
Hometown model with the following fields: name

A single record from Person.objects.values() will looks like this

{"id": 1
 "first_name": "first name",
 "last_name": "last name",
 "hometown__id": 1,
 "hometown__name": "town name",
}


I propose adding a nested optional parameter to values, where a single 
record from Person.objects.values(nested=True) will look like

{"id": 1
 "first_name": "first name",
 "last_name": "last name",
 "hometown": {
  "id": 1,
  "name": "town name"
  }
}


This feature is needed given that most APIs these days are nested, while 
it's simple to implement, I think it's much better to have it a built-in 
django feature.

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8e5cbc9a-0317-40d3-8038-5b4300738b90%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Allow impossible model validation (mainly admin and generic forms)

2015-11-25 Thread Vlastimil Zíma


Django assumes that all input data in forms can be validated by 
`Form.is_valid()` which in some cases is not true. Database contraints, 
e.g. unique, can fail even though they are checked. An application may 
require communication with other servers while processing data which can 
lead to errors. But these conditions are not expected by regular Django 
form flow and an attempt to handle these cases results in large overriding 
of default implementation.


This topic was previously discussed here 
https://groups.google.com/d/topic/django-developers/rzjpP0byNQo/discussion, 
but discussion was mainly based on race condition in unique check. I'd like 
to reopen the topic because there are other possibilities which may cause 
the possibility of failure after form validation to become real, especially 
if network connection is involved.


I suggest Django should provide mechanism which allow handling the 
unexpected failures after form validation, e.g. expect `ValidationError` to 
be raised by `ModelAdmin.save_model`.


I started this discussion as a result of wontfix from 
https://code.djangoproject.com/ticket/25777.


Vlastik

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b845bfbc-1020-4277-81c5-6fb97c302f98%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.