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,
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
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 fail
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 suppo
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
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
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 ext
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
t
> 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
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.)
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
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
> **kwarg
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 li
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:
>
> Th
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(A
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
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 databa
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 ac
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
>
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 Djan
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
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 error
22 matches
Mail list logo
