Apologies for some reason I didn't get any replies to my inbox! If you'd
like to tag me on any WIP PRs I'm willing to lend a hand and test.
On Thursday, 7 April 2022 at 22:19:44 UTC+10 revan...@almabase.com wrote:
>
> Hi Josh,
>
> I am also interested to work on this ticket. I am also aware of h
I've opened the ticket https://code.djangoproject.com/ticket/23753 to track
which functions should be implemented.
--
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 re
added to the query
>> and how they are evaluated
>> - Aggregates behave similarly to other ORM expressions
>>
>> A pull request by Josh Smeaton implements the DEP (
>> https://github.com/django/django/pull/2496).
>>
>> My understanding is that we don'
Just a quick FYI
-
https://groups.google.com/forum/#!msg/django-developers/N0HEAD1ht8k/GQJ77RLUydsJ
I tried to implement fixture loading in setupClass() and ran into a few
difficulties. I did a lot of profiling though. You get about a factor of 3
speedup for tests that use fixtures. It only re
I don't think a doc patch is sufficient to address the problem, and I
highly doubt that a warning would be heard by the vast majority. The
attention this bug needs is someone to write a patch to fix the code.
Looking at the ticket, 4 weeks ago someone suggested some code that *may*
fix the prob
Clever. I don't mind this approach at all. Will the overriding of
get_db_prep_lookup interfere with other implementations though?
On Sunday, 16 November 2014 06:03:18 UTC+11, Shai Berger wrote:
>
> Hi,
>
> I'v been working on an old Oracle bug[1], and realized that a nice way to
> solve it woul
Hi Michael,
Great to see new expressions being used already! Speaking specifically
about the Case structure, I think it looks nice. I was planning on writing
a few functions (https://code.djangoproject.com/ticket/23753) which
included Case/When of some description.
My idea of a Case API was:
To me, "sane default" means django should not silently alter the query to
provide a LIMIT when it is not asked for.
I have also run into situations where doing a .count() or iterating a full
table has broken the application, or put too much pressure on the database.
Specifically with django bin
Trac user jbg has found a regression with the aggregation/annotation
refactor #14030. The crux of the problem comes down to whether annotations
and aggregations should respect constraints on model fields. The specific
example raised is as follows:
Model.objects.aggregate(
sum_price=Sum('pri
Thanks for all the comments. I'll address the relevant bits below.
> So, if the user explicitly asks for max_digits=3 in the output_field
> argument, then we should enforce that. Or, alternatively we should
> disallow setting max_digits for explicit output_field in expressions.
>
I don't kno
I've marked the patch as ready for checkin. Instantiating fields without
any arguments for decimal field is now supported by all backends. The
format_number function has learnt to understand max_digits or
decimal_places being None. The format_number function needs review though.
When decimal_pl
I've been maintaining a custom django backend for quite awhile now. It
delegates authentication and authorization to an internal API. I do not use
a custom User model at all.
The backend completely handles the reset/change password logic, and the
form uses the methods on the backend directly. I
https://gist.github.com/jarshwah/c5b9abebb452f2e3286f
I've removed some of the error handling and custom application bits, and
I've also renamed the classes. But this is the meat of auth for my project.
You'll notice that the backend is hardcoded in the constructor, because we
only use this bac
Correct - I've updated the
gist: https://gist.github.com/jarshwah/c5b9abebb452f2e3286f
--
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, sen
Ok, I see where your suggestions could make a lot of sense. Thanks for
persisting with me.
I've updated my gist again with what a refactor could allow it to look
like: https://gist.github.com/jarshwah/c5b9abebb452f2e3286f
The backend remains unchanged. The form removes most custom handling,
as
Hi Michal,
I'm about ready to implement Case/When expressions, do you mind if I use
your implementation? Also, do you think it's necessary or desirable to have
a SimpleCase and a Case?
Josh
On Wednesday, 19 November 2014 08:34:10 UTC+11, Michał Modzelewski wrote:
>
> I've put my code up on git
On Tuesday, 16 December 2014 18:23:29 UTC+11, Michał Modzelewski wrote:
>
> Sure. I was planning to work on it myself, but wanted to discuss API,
> passing in output_fields, and casting results first.
> I started with 2 classes because I only needed SimpleCase first to
> implement the bulk_update
I admit I don't fully understand how generic relations work (I try not to
use them in my projects), but I would think we should be able to make
annotations work properly with them. Now that aggregates are based
internally on F() objects, we should be able to special case F() for
generic relatio
:28:53 UTC+11, Tim Graham wrote:
>
> Unlike in previous release cycles, we are going to try a complete feature
> freeze at alpha. The details are outlined here:
>
> https://code.djangoproject.com/wiki/Version1.8Roadmap
>
> On Tuesday, December 16, 2014 8:01:23 PM UTC-5, Josh
Would you mind linking to the ticket you're talking about? Will encourage
more people to participate if they don't have to search Trac for it ;)
Josh
On Monday, 22 December 2014 01:05:14 UTC+11, Brian Faherty wrote:
>
> Hey Folks,
> Teams I have been on in the past have used natural keys exten
So he did, Flux must have killed link colours for me.
Sorry folks!
On Monday, 22 December 2014 10:50:22 UTC+11, Russell Keith-Magee wrote:
>
>
> On Sun, Dec 21, 2014 at 10:33 PM, Josh Smeaton > wrote:
>>
>> Would you mind linking to the ticket you're talking a
fore
then. I'm happy to pick up your work and finish it off if you haven't got
the time to do it though. Just thought I'd give you the chance since you've
put in the effort.
Josh
On Wednesday, 18 June 2014 07:51:31 UTC+10, Tim Martin wrote:
>
> On Monday, 16 June 201
Congratulations on taking this all the way Daniel!
On Thursday, 8 January 2015 12:14:52 UTC+11, Daniel Pyrathon wrote:
>
> Hi all,
>
> My project has just landed in master, since last night (EU time).
>
> I just wanted to say THANK YOU for everyone that helped me review and fix
> my project. I wo
>From my experience some reusable apps require (in their documentation) that
specific context_processors are installed. I'm also -0 unless some decent
alternative exists and there's a convincing argument why they aren't a good
feature to have.
Cheers
On Sunday, 11 January 2015 14:33:44 UTC+11,
Definitely. I don't think any of the patches I've written have sat without
review for longer than a day or two. The turn around on feedback has been
amazing. I really hope this program is picked up again. Thanks Tim and
Berker.
- Josh
On Tuesday, 20 January 2015 17:16:39 UTC+11, Anssi Kääriäin
I don't think there is enough time in GSOC to properly extract so many
components into separate packages. I don't even know if this would be a
long term goal for Django. Even if it were, there's more to it than just
creating a new repository. Maintainers would have to put their hand up to
manag
Just quickly, HSTS[0] and X-Frame-Options[1] are supported and recommended
in the security documentation already. As you point out though, HSTS isn't
yet a full solution, and, frankly, it scares me a little. Personally, I
redirect the / path to HTTPS from HTTP and drop all other HTTP connections
1, Jon Dufresne wrote:
>
> On Tue, Feb 3, 2015 at 7:09 PM, Josh Smeaton > wrote:
> > Just quickly, HSTS[0] and X-Frame-Options[1] are supported and
> recommended
> > in the security documentation already. As you point out though, HSTS
> isn't
> > yet
Hi Andriy,
The direction looks OK to me, but it'll be a lot easier to review properly
once you've opened a pull request.
I'm not sure that you need to separate out "general" and "statistics" into
different modules, but that's something we can discuss on the PR.
Nice work :)
Josh
On Tuesday,
To expand on Florians reply, why do you think replacing the routing
infrastructure is a good idea? Is there any tangible benefit in doing so?
Can you demonstrate that you can stay completely backwards compatible while
realising those benefits? If there answer is no to benefits or backwards
comp
As Tim pointed out, it's unlikely that the change would have made Alpha,
let alone Beta. Adding a new feature now breaks the 'philosophical' release
rules but it also allows a feature through without the wider community
testing in alpha and beta (now that it's cut). As far as I can tell,
increa
>
> Contributing to contrib.postgres is a possible
> option, but it's not really a postgres specific feature -- almost all
> of the major database vendors support it (sqlite being as always the
> obvious exception).
>
This option worries me. I definitely do not like the idea of building a
fe
The concept of batched SELECT statements doesn't really exist in SQL,
unless the relations you're selecting have identical column types. Example:
SELECT name, age_in_years FROM person
UNION ALL
SELECT item_name, quantity FROM item;
The UNION here means combine the results of each query into the
Hey Thomas,
You've only waited 11 hours for a response here. Your contributions are
definitely welcome, and it's obvious that you've done a lot of work and put
in a lot of effort. Personally, I thank you.
The reason you're not getting a response, at this point, is because the
number of people
With regards to the field API - that probably doesn't need an ML
discussion. Open a ticket on Trac, submit a PR, and the people that will
want to see it will review it. If there's confusion about how to proceed,
then an ML discussion can be had, when there are actually interested
parties involv
Great stuff Erik. This will greatly simplify how we validate passwords!
One thing I'd like to note is that it is extremely frustrating when a form
fails validation with an error message, you fix that particular problem,
and you're given the next error message. Ideally, all validators would run
Hi,
Firstly (and least importantly) opening a PR makes it a lot easier to
review code, especially when there are lots of commits. A [WIP] pull
request is common and useful. If you get a chance, you should open one with
this change.
I think it's a good idea. So much so that I opened a ticket ab
FWIW I put a rough patch together awhile ago (I can't find it or the
discussion unfortunately) that attempted to make Transforms usable as
expressions.
They share partial APIs but not the full set which made that first attempt
quite messy/hacky. I'm not aware of any reasons that they couldn't be
o, I was just wondering if it worked already. Since it doesn't, that'll be
something I look to implement after your patch is ready.
Cheers
On Wednesday, 25 March 2015 23:36:11 UTC+11, Jon Dufresne wrote:
>
> On Tue, Mar 24, 2015 at 9:24 PM, Josh Smeaton > wrote:
> &
Also, found the patch I
wrote: https://gist.github.com/jarshwah/a541857db195f0486b9e
Instead of multiple subclasses, perhaps Func could take on some of the
functionality of transform directly, but that makes no sense for > 1 arity
functions. A nice design should be able to be found.
On Thursda
t; usage in QuerySet.datetimes. Maybe this could be treated as a bug, and a
> patch for the error message could be backported?
> This would also close https://code.djangoproject.com/ticket/10302
>
> For 1.9 Date and DateTime could become importable from django.db.models
> like
Hi Daniel,
Can you provide links to the patches and discussion you're referring to?
It'll be easier to provide some feedback if we have the detail in front of
us.
I'm all for improving performance for the Oracle backend - as long as
backwards compatibility or correctness doesn't suffer. If eit
Could we selectively set the numberasstring property per query if there are any
decimal fields for that particular query? I guess this could help in the
interim until/if cx_oracle can fix the problem and that particular version of
cx oracle becomes the minimum version django supports.
--
You
Forgive me, but wouldn't you just declare those views as csrf_exempt? A
csrf token at one site isn't going to be valid at another, right?
On Friday, 29 May 2015 13:44:42 UTC+10, Troy Grosfield wrote:
>
> I have the following domain and subdomains both are trusted and both are
> secure (https):
>
There's definite room for improvement with regards to the deployment story
at the end of the tutorial. I don't think pointing people to hosting
companies is the right way to go though, because they're not getting
information on how to deploy from those links.
> There could be an argument to doc
You're referring to a "pepper" - a site wide secret that's supposed to be
used, in some way, to further encrypt passwords. As far as I'm aware there
are no algorithms available that take a pepper into consideration. Further,
I don't see the need for the inclusion of a pepper if the password
enc
I really like Ryan's second proposal (quoting here again):
2.2 - 0 mos - (LTS) No features dropped
> *3.0 - 8 mos - All deprecations, including the LTS deprecations, are
> removed *
> 3.1 - 16 mos - No features dropped
> 3.2 - 24 mos - (LTS) No features dropped
> *4.0 - 32 mos - All deprecatio
I'm also +1 on the proposal as it stands, and neutral on when the semver
versioning should begin.
On Wednesday, 17 June 2015 05:03:47 UTC+10, Michael Manfre wrote:
>
> I'm +1 on the Google doc proposal and like Markus, I support relabeling
> 1.9 to 2.0 to line the versions up with the new paradi
There are a couple of problems with this proposal IMO.
1) The .djangorc file would need to be somewhere on the file system (like
~/.djangorc), because you want it for the startproject command, it can't be
deployed with startproject
2) It doesn't seem to provide that big a benefit
3) A simple bas
I was worried about 1.10 because I wrongly assumed that the entire version
string was ordered. SemVer (and https://www.python.org/dev/peps/pep-0386/)
specifically call out that each component of a version identifier MUST be
ordered numerically. My objections based on that incorrect assumption I
I'm not quite up to date on XML in databases (I've never had to use XML in
a database), but don't the majority of core backends support XML in some
way? If so, I'd probably like to see an attempt to build out XML support
such that all/most core databases could benefit from the new feature,
rath
Can you explain/give an example of grouping over non relations? I'll see if
I can translate that to expressions in their current form.
On Tuesday, 4 August 2015 07:10:05 UTC+10, Shai Berger wrote:
>
> On Monday 03 August 2015 10:27:14 Anssi Kääriäinen wrote:
> > You can annotate raw SQL with ex
You're right about that. You can aggregate over custom expressions. For
aggregating over enums you should be able to use case expressions
On Wed, 5 Aug 2015 at 05:05 Anssi Kääriäinen wrote:
> On Tuesday, August 4, 2015, Shai Berger wrote:
>>
>> The classic database aggregation examples involve
Your "scare quotes" for "feature" are really disappointing. Especially
considering that the checks were hardcoded and couldn't be silenced prior
to the "system check framework".
> Working with Django is getting harder with every new version.
If you want to turn off new features or extension poi
Hi Petr,
Thanks for working on that ticket. I'm probably not the person to be
reviewing work in the admin, but here are a few ideas for getting your
patch noticed.
1. Create a pull request against the Django repository. Even if it's not
ready to be merged, a pull request makes it a lot easier
Can we just push the ifequal type tags through regular deprecation? As
mentioned, the cost of maintaining the tags is extremely low. Remove the
ifequal tags from the docs, document their deprecation, and remove in
Django 2.0.
On Friday, 7 August 2015 11:56:29 UTC+10, Curtis Maloney wrote:
>
> G
Fair enough, I don't necessarily disagree with you. Would removing the
documentation for ifequal be OK? At least that would prevent new projects
from using it or being confused about multiple ways to compare values.
On Friday, 7 August 2015 12:49:37 UTC+10, Karen Tracey wrote:
>
> We certainly w
Hi Alexey,
I find this approach really interesting, and I don't mind the API you've
created at all. Even if this doesn't make it into Django, I think there's
enough utility in your library that other people would want to use it. I'm
not going to comment on specifics just yet like method names,
I'll also stick my hand up to be involved with the Oracle backend, but not
the Oracle GIS backend. I don't have a lot of time available at the moment,
but I'll be able to support Jani and anyone else that's interested in
maintaining the backend.
Cheers
On Wednesday, 19 August 2015 16:36:23 UTC
I agree with Shai. There are certain companies that have bought extended
support for WinXP/IE8 for extravagant amounts of money. That means
Microsoft is taking on the burden of support (security) for those systems.
They are EOL as far as we're concerned. We shouldn't intentionally cripple
suppo
t; -path
> >> '-user__last_login_date'
> >>
> >> or even
> >>
> >> >>> -p
> >> NegP('user__last_login_date')
> >>
> >> Is it possible path subtraction is required in future by any reason? In
> &
>My own opinion is that if you really need IE8 support, it's not difficult
to write a custom template and conditionally include the old jQuery version.
Good point. It's easy enough for users to support IE8 themselves if they
need to. Consider me a +1 then.
On Thursday, 20 August 2015 00:34:01 U
the CSS, our own custom javascript,
> new jquery features, community plugins will drop it etc etc. For 1.9 itself
> it may simply be a case of swapping in a different jQuery version, but it
> won't stay that way for long.
>
> On 20 August 2015 at 00:49, Josh Smeaton > wrote:
&g
6:45 UTC+10, Alexey Zankevich wrote:
>
> What about the idea to add interface to specify paths with special class
> or callable?
>
>
> On Wednesday, August 19, 2015 at 10:49:07 AM UTC+3, Josh Smeaton wrote:
>>
>> If I finish the patch in time (I think I have about a month
(since I'm talking about general interface to
> specify query paths in the whole project).
> So, I suggest a separate class for that purposes, and it doesn't
> necessarily need to have short name like "P". Even better if it has
> meaningful name like "
Generally, I'm a fan of adding repr methods. I don't think we should run
around finding all the places they might be useful and adding them, but if
someone is to put forward patches where they've noticed a benefit, we
should encourage that.
I'm not sure I fully understand your concerns though.
Marcin is correct. The plan is to extend the concept of expressions so that
you have more control over crafting your own queries.
What we have:
- select expressions
- aggregation expressions
- case/when
- order by
- where expressions (lookups/transforms)
- column expressions (representing model
t 8:59:37 PM UTC-4, Josh Smeaton wrote:
>>
>> Generally, I'm a fan of adding repr methods. I don't think we should run
>> around finding all the places they might be useful and adding them, but if
>> someone is to put forward patches where they've noticed a b
Most of the classes used by Django wouldn't be able to support
eval(repr(obj)) anyway, because nearly everything accepts complex types.
You'd have to recursively implement strict repr methods all the way up the
stack such that repr becomes too unwieldy for effective debugging.
If there are type
I don't think removing the default list from the template is the right
idea. We'd be sacrificing some production users that don't go through
security options on deployment checklists to better support development
environments where the security issue (probably) isn't present. I do think
we need
f not DEBUG else []
>
> Of course this depends on whether or not you expect other places like the
> admin's change password form to do validation in debug mode.
>
> On Monday, September 7, 2015 at 8:09:00 PM UTC-4, Aron Podrigal wrote:
>>
>> I started using django-c
Is the concern that 100,000 iterations is too slow on python < 2.7.8 but is
acceptable on versions after that? If so, then we wouldn't be breaking <
2.7.8, we'd just be reducing the performance profile, right? We could call
out such things in the release notes.
On Tuesday, 22 September 2015 02
Hi Varun,
If you believe you've found a bug, then please open a ticket on trac
here: https://code.djangoproject.com/newticket
We can then discuss on the ticket whether or not the bug exists, and I can
try to help you figure out how to fix it.
Thanks,
On Tuesday, 22 September 2015 07:06:03 UTC
> While this makes sense, the use of TextField is also for the purpose of
having rendered a text widget for ModelForms. So we should allow a
max_length of None for both.
If you use Oracle (or mysql I guess), you get used to manually changing the
form field widget to be a TextArea if that's what
>
> Could we have permanent backward-compatible (no deprecation timeline)
> shims? I'm -0 if not because it's yet-another thing that everyone needs to
> change when upgrading.
>
> +1
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributio
1. Lookups should become Expressions, just as Transforms have become
Expressions. This will let us process Lookup arguments as Expressions all
the way the way through. I think this should be a major goal for version
1.11.
2. Chaining transforms is now possible since they are just Func
expressi
gt; We don't seem to be missing any major parts. I (or some volunteer)
> just need to finish the PRs, and then we should be really close to
> full support for expressions in filter.
>
> Josh: do you think we could get Lookup as expressions in to 1.10
> instead of 1.11?
>
>
I'm mixing my versions, sorry to those following along. 1.9 has just
reached alpha. Lookups as Expressions should be doable for 1.10 which
master is currently tracking.
Cheers
On Wednesday, 30 September 2015 15:31:24 UTC+10, Josh Smeaton wrote:
>
> The alpha for 1.10 has already be
-to-subq support for Lookups before we make
>> them expressions. Lookups as expressions are usable outside .filter(),
>> and we need the split-to-subq support only in .filter(expression).
>>
>> - Anssi
>>
>> On Wed, Sep 30, 2015 at 8:46 AM, Josh Smeaton
Hi David,
There are a few undocumented expressions in the expressions module because
they aren't intended to be used by the public. The Date and DateTime
expressions you reference were actually moved from elsewhere (if memory
serves) during the expressions refactor. They were previously very th
work:
>
> MyModel.objects.filter(date1__month=F('date2__month'))
>
>
> Additionally, is there a reason why Combinable/F couldn't figure out its
> own output_field type (at least in some cases? e.g (DateField - DateField)
> --> DurationField) , as opposed to hav
for this (it is actually
>> >> > surprisingly easy to do once we have support for expressions in
>> >> > filter).
>> >>
>> >> I'm pretty convinced we need a better API / sugar as part of core in
>> the
>> >> long run.
>> >>
e easy
> to document and testing would be a breeze. What do you think?
>
> I'll create a new ticket and get started on this tomorrow after work. I
> expect to have a PR compiled by Wednesday night, but take a little longer.
>
>
> On Sunday, October 18, 2015 at 9:56:51 PM
Having pluggable 2fa backends is a great idea.
Many sites that allow 2fa have it as an option per user. I would think
Django would allow the same. Allow admins to force 2fa, or allow Users to
choose if they'd like it enabled.
There'd have to be ORM/Model support (presumably) for user choices. A
Hi José,
Can I just clarify the problem for a second.
Are you saying that inspectdb isn't returning output for tables owned by a
separate user but visible to the django User? If so, there's an argument to
be made about correcting that behaviour and just generating everything
visible. Of course
I'm not sure something like this should live inside Django proper. There is
nothing to guarantee that a user model will have an email address even
though the standard builtins do. I'd feel better about having this
functionality provided by a library, maybe even by django-registration
which we'r
The version of Django you use is going to have a large (code) impact on
what is actually happening when calling values_list. The
Values[List]QuerySet classes are gone in 1.9. 1.8 implemented a
different/better way of converting values from the database to python.
from_db_value came about in 1.8
fore making any post, but I apreciate the fast responses!
> Perhaps it would be a good idea to warn about values_list bottleneck on
> 1.7!
>
>
> El lunes, 16 de noviembre de 2015, 21:30:35 (UTC-3), Josh Smeaton escribió:
>>
>> The version of Django you use is going to ha
e see some good numbers alongside said patch.
I'll leave it there for now personally. Welcome further investigation if
someone would like to run with it :)
On Tuesday, 17 November 2015 11:51:04 UTC+11, Josh Smeaton wrote:
>
> Hey,
>
> Nice to see most of the performance difference
It might be a bit early in the day for me, but isn't that query already
optimised? That is, it's already eliminated a join. It hasn't joined to the
"Especialidad" table, it's only joined to the intermediate table. I *think*
the join to the intermediate table is necessary because there could be
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
Shouldn't we decide if we want to support pypy first? By putting it on CI
that's an implicit agreement to support pypy potentially at the cost of
certain features.
There's also the consideration that python2 is going away in django 2.0, so
if pypy3 isn't up to date wrt python3, we'd have to dro
I agree with the ticket. The imbalance between is_superuser and
is_authenticated() should be enough to consider updating the API. The
security concerns and, in particular, Aymeric's Jinja example, make this
ticket more compelling.
I think we should be asking.. why not? If there's not a good rea
I thought I'd responded to that ticket with a similar suggestion but I must
have clicked away before submitting.
Yes, providing a transform would be ideal. Unfortunately order_by does not
support __lookup syntax. Adding __lookup syntax support to F() is tracked
here https://code.djangoproject.c
I agree with Tim. Unless someone puts their hand up to say they definitely
require python 3.2 support for 1.8, I think it makes sense to drop support
in the next dot release of 1.8. 3.2 isn't an easy python to find in the
wild as far as I know, so I'd be surprised if there was any real support
>
> Also, some random feature requests:
>
>- .values(‘stuff’, my_thing=Coalesce(‘thing’, ‘stuff’)) should work
>
> I thought this was already tracked but I couldn't find an existing
ticket. So I created it: https://code.djangoproject.com/ticket/25871
Feel free to leave comments there if
Yeah I'm wary that a lot of the problems with extra() will be replicated by
users switching to RawSQL() instead. It won't handle realiasing or group by
correctly.
On Tuesday, 8 December 2015 18:26:52 UTC+11, Anssi Kääriäinen wrote:
>
>
>
> On Tuesday, December 8, 2015 at 3:16:20 AM UTC+2, Michae
As far as I'm concerned, anything we can do to simplify and decouple
abstraction layers is a good thing and would be welcomed, with the usual
caveats of backwards compatibility in public and pseudo-public APIs.
models.query is a thin layer over models.sql.query. That's a good thing.
Ideally, mo
en,
> since its primarily about restructuring the existing code. It doesn't
> however feel like a small change, and no matter how I cut it up, at some
> point there would likely need to be a fairly big "cut over" PR. Not really
> in the spirit of lots of sm
I think this is a fairly big oversight that should be fixed in the most
backwards compatible way, so users don't need to change their code, or only
have to change it minimally. I'm with Aymeric here. Does Django have
visibility of the field constraints at insert/select queryset time? Ideally
Dj
1 - 100 of 388 matches
Mail list logo
