On Tuesday 10 June 2014 02:48:14 Josh Smeaton wrote:
> > However, I think having some special case code in filter(), annotate()
>
> and anything else that takes expressions would be OK
>
> I strongly disagree with this. Expressions are context insensitive at the
> moment, which means they can be
Hi all,
Bug #22816[1] is a test failure on Oracle. It was caused by the introduction
of the "can_introspect_null" database-feature-flag, which was set to True for
all core database backends except for Oracle; and use of that flag in the test
of introspection of NullBooleanField. The easiest way
On Friday 13 June 2014 08:52:29 Aymeric Augustin wrote:
> > Le 13 juin 2014 à 01:30, Michael Manfre a écrit :
> >> On Thu, Jun 12, 2014 at 6:17 PM, Shai Berger wrote:
> >>
> >> Bug #22816[1] is a test failure on Oracle. It was caused by the
> >>
Hi Tim and all,
On Saturday 14 June 2014 03:52:57 Tim Graham wrote:
>
> Release - GA Date - Premier Support Ends - Extended Support Ends
>
> 11.1 - Aug 2007 - Aug 2012 - Aug 2015
> 10.2 - Jul 2005 - Jul 2010 - Jul 2013
> 10.1 Jan 2004 - Jan 2009 - Jan 2012
> 9.2 Jul 2002 - Jul 2007 - Jul 2010
>
Hi guys,
TL;DR -- ...sorry, there's no TL;DR here. It's a bunch of separate ideas. It's
a little lengthy. Please bear with me.
I'd like to compare our support for old database servers with our support
for old browsers. We only recently dropped code that supported IE 6/7 (!)
for a security (!) fix
On Sunday 15 June 2014 10:59:17 Michael Manfre wrote:
> I don't see how it should be up to Django to continue to support all of
> these archaic versions of Oracle. To paraphrase the mantra repeated during
> various mssql discussions, "Django doesn't need to include everything in
> core, it just nee
Hi Renato,
Sorry for being a little late to this party.
On Sunday 01 June 2014 17:36:43 Renato Oliveira wrote:
>
> Yeah, i'm aware of this, and sorry for not being explicit. The goal of this
> improvement is to point to many places. For exampe, if I have a project
> with, bootstrap, jquery and a
On Monday 16 June 2014 20:09:13 Greg Chapple wrote:
> Would "Ready for merge" not be a more appropriate term? To me, check-in is
> a term I would associate with SVN.
>
Yes, except that RFM sounds more like "Read Forgotten Manual" :)
Shai.
--
You received this message because you are subscribed
On Tuesday 17 June 2014 13:53:25 Aymeric Augustin wrote:
> 2014-06-17 12:26 GMT+02:00 Rahul :
> > It introspect Boolean field as SmallIntegerField but in the test case if
> > can_introspect_boolean_field=False then it checks only for IntegerField.
> > By including introspect_boolean_field_as_smallI
Hi,
On Tuesday 17 June 2014 16:41:04 Jason Skicewicz wrote:
> >
> > AttributeError: 'str' object has no attribute '_meta'
>
> I'm at a loss as to why this is happening, but through debugging, when
> Django attempts to get the field via script, lookup_model is a string
> whereas in the view code,
Hi,
A minor style point:
On Thursday 19 June 2014 02:56:10 Josh Smeaton wrote:
>
> class Lower(Func):
> function = 'LOWER'
>
>[...]
>
> def mongo_lower(self, compiler, connection):
> self.function = '$toLower'
> return self.as_sql(compiler, connection)
>
> setattr(Lower, 'as_mongo
On Monday 30 June 2014 17:11:22 Josh Smeaton wrote:
> This is how we think we can ask 3rd party backends to provide
> implementations for functions they need to modify:
>
>
> class DatabaseWrapper(BaseDatabaseWrapper):
>
> def __init__(self, *args, **kwargs):
> self.patch_functions()
On Monday 14 July 2014 20:07:16 Collin Anderson wrote:
> Hi All,
>
> I just saw #23015 come through (1.9 -> 2.0 not an earth-shattering
> release). I think it's a little ridiculous that decimal point doesn't
> really mean anything.
>
> I'm wondering if it would make sense, after 2.0, to follow Ch
+1
What they said.
On Wednesday 23 July 2014 23:47:41 Paul McMillan wrote:
> +1
>
> Thanks for your hard work, Aymeric.
>
> -Paul
>
> On Wed, Jul 23, 2014 at 12:25 PM, charettes wrote:
> > +1
> >
> > Thanks for putting this up together Aymeric
> >
> > Simon
> >
> > Le mercredi 23 juillet 2
Hi,
> On 08/06/2014 03:30 PM, Tim Graham wrote:
> > I proposed the idea a couple months ago and got several +1's. The main
> > concern was from Shai, "not quite -1, but a strong -0 on "blessing" any
> > single oAuth provider. GitHub is fine, but so are Google, StackExchange,
> > and even the Evil
On Friday 08 August 2014 01:49:55 Ben Finney wrote:
> Aymeric Augustin writes:
> > GitHub doesn't require creating a new account, since anyone interested
> > in contributing to Django should have a GitHub account already to
> > submit pull requests.
>
> This seems to be a common assumption, but i
On Saturday 09 August 2014 01:38:32 Curtis Maloney wrote:
> For what it's worth, I can understand the opposition to requiring a GH
> login [ostensibly a "coders" account] in order to make comments on tickets.
>
> However, if you're opinionated on a ticket you're either a coder, or feel
> strongly
On Friday 08 August 2014 10:41:20 Anssi Kääriäinen wrote:
>
> As for addition of .exists lookup - how
> should .filter(somefield__exists=False, somefield__othercol=2) work?
It should be noted that __exists is a little special. For the False case
above,
.filter(somefield__exists=False, somefield
On Wednesday 13 August 2014 09:55:33 Anssi Kääriäinen wrote:
>
> But, how about .filter(Q(somefield__exists=False) |
> Q(somefield__othercol=2))? This one should return results only if there
> are no somefield related instances at all, or if there are related
> instances, then at least one of thos
Hi,
It seems to me that the taxonomy doesn't handle well FileField and ImageField.
It could be bundled in with ForeignKey (as the data it really represents is
only pointed at by the related column data), but not with the current wording.
For ImageField, there is -- in addition to the above -- t
On Sunday 17 August 2014 17:36:12 Michael Manfre wrote:
> AssertNumQueries is often a problem for 3rd party backends.
> AssertMaxQueries would become the same and likely result in poorly written
> tests because of the inherent slop factor in the arbitrarily chosen max
> value.
>
I agree with the
Hi again,
Below, ">D" are quotations from Daniel's message I'm replying to, and
">R" are from Russell's message that opened this thread.
>D *Regarding FileField*
It took me some time to clear for myself why FileField is a data field, and not
like FK: The point is not where the data is stored
On Wednesday 20 August 2014 10:29:49 Anssi Kääriäinen wrote:
> On Wednesday, August 20, 2014 11:19:33 AM UTC+3, Russell Keith-Magee wrote:
> >
> > This yields the following formal API for _meta:
> > * get_fields(data, many_to_many, related, include_hidden,
> > include_parents)
Hi Daniel,
On Thursday 21 August 2014 22:53:36 Daniel Pyrathon wrote:
>
> On Wednesday, August 20, 2014 8:21:36 PM UTC+2, Shai Berger wrote:
> > makes me itch a little as well -- mostly, because each of the objects
> > returned by the property is not a related-object, but r
Hi,
As this is the 4th example I see of a templating engine that is inspired by
the Django Template Language, I started a small collection of them on the
wiki[1]. I usually work with other parts of Django, but thought people who are
more into the front-end might find this interesting.
HTH,
On Wednesday 20 August 2014 00:57:01 Chris Foresman wrote:
> On Tuesday, August 19, 2014 4:53:39 PM UTC-5, Chris Foresman wrote:
> > On Tuesday, August 19, 2014 4:49:10 PM UTC-5, Chris Foresman wrote:
> >> On Monday, August 18, 2014 12:05:55 PM UTC-5, Florian Apolloner wrote:
> >>> Validation error
On Sunday 24 August 2014 20:44:30 Aymeric Augustin wrote:
>
> Eventually, I managed to set up DjangoProject and GitHub auth in parallel.
>
> Contributors who refuse GitHub's ToS can participate on Trac again.
>
> Issues created by username mismatches have been dealt with.
Thanks, Aymeric, for e
Big +1.
I suspect this also opens the door to a significant speed improvement for
Oracle's number column handling, but I'll have to investigate further (ask me
about numbers_as_strings if you're interested in details).
Thanks for the great work,
Shai.
--
You received this message because yo
This was a deliberate change, I think it was discussed on the list but maybe
just IRC. The tutorial was changed to reflect it, if any documentation still
says otherwise it is a documentation bug.
On 31 באוגוסט 2014 18:23:58 GMT+03:00, Yo-Yo Ma
wrote:
>(continued)
>
>I'm using Django 1.7c3, an
This thread has had very little to do with django-secure for some time...
On Sunday 31 August 2014 18:07:04 Carl Meyer wrote:
>
> In the case of the email settings, I think introducing a deprecation
> that requires people to update their settings files, for zero gain in
> capability, is a much bi
On Tuesday 02 September 2014 15:27:53 Josh Smeaton wrote:
>
> As far as I'm concerned, using fixtures is the wrong way to populate data
> for tests. You're much better off creating the objects you need for each
> test within the test, or creating them directly inside the setUp method.
+1.
> You
Ben,
Two points:
A) Your description of the threat-of-use-of-CoC incident, which appears to be
quite central to your argument (as a piece of evidence), is, as far as I can
see, inaccurate. The person who was threatened had started out reasonable, but
later made several disrespectful and prejud
Hi,
I'm looking into the details of migrations a little, and I ran into this
issue.
I have two migrations: The first creates a model, the second adds another
model and a field to the first model. I'd expect squashmigrations to patch the
AddField into the first CreateModel, but it finds "No opt
Replying to myself:
On Sunday 21 September 2014 20:59:46 Shai Berger wrote:
> Hi,
>
> I'm looking into the details of migrations a little, and I ran into this
> issue.
>
> I have two migrations: The first creates a model, the second adds another
> model and a fie
Hi all,
I gave a talk to a local user-group about the migrations in 1.7, and some
people in the audience raised things they would like to be able to do, and are
not supported by the current framework; thought it would be nice to bring them
here.
Two issues were about handling migrations at the
Hi Peter,
Thanks for asking!
On Sunday 28 September 2014 02:01:59 Peter Geoghegan wrote:
>
> * Would you consider the syntax that I've proposed a good one?
>
Looks pretty reasonable.
> * If it was available, would you use it in future versions of Django?
> Do you think the plugins ecosystem c
On Sunday 28 September 2014 09:33:06 Simon Riggs wrote:
> On 28 September 2014 02:22, Shai Berger wrote:
> > Upon reading the docs, I was a little surprised to see that in terms of
> > triggers etc, the operation is always considered an INSERT. I would
> > expect it to be con
On Thursday 09 October 2014 09:53:44 Andrew Godwin wrote:
>
> The logic is not too complex, but the feature would need to be
> dependency-aware and delete any migrations that depended on the updated
> migration before it re-ran makemigrations; in addition, if no migration
> name is provided (as to
Hi Uri,
On Friday 17 October 2014 01:30:10 Uri P wrote:
> Thanks Andrew for enlightening me. That was helpful.
>
> Anyway, for me personally, data migration is the easiest part, I can do it
> in a heartbeat by a simple script.
> In contrary, solving circular dependencies seems to be very difficul
Hi all,
For a very long time -- as far as I'm aware, forever -- we've had, in our
cursor classes, a "callproc()" method that follows the callproc() definition of
pep249[1]; this allows database stored procedures to be called.
Recently, we've had a ticket[2] and PR[3] to enhance this method -- t
9, much like
its siblings execute(), fetchone() etc; that is why I am not even suggesting
to modify it to the obvious callproc(procname, *args, **kwargs).
Cursor.execute() is documented, public API -- are there reasons to deny
callproc() the same status?
Shai.
> On 19 October 2014 00:25,
Hi Ronaldo,
This forum is dedicated to discussions about the development *of* Django; for
questions about development *with* Django, please use the django-users list.
Thanks,
Shai.
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contri
On Monday 20 October 2014 00:38:52 Marc Tamlyn wrote:
> I was thinking in the context of a project - creating a procedure to use in
> the code.
Oh, I see. Your API suggestion is also perfect for that use.
> Naturally cursor.execute() is perfectly fine for tests, which
> would need to be backend
On Tuesday 21 October 2014 18:23:44 Chris Foresman wrote:
> Is there some benefit to using `.callproc()` over this?
>
> ``` python
> query = 'CALL sp_recommendation_engine(%s, %s)'
> profile = user.get_profile()
> cursor = connection.cursor()
> cursor.execute(query, [user.id, profi
On Monday 20 October 2014 21:26:50 Carl Meyer wrote:
> Hi Marc,
>
> On 10/19/2014 12:54 AM, Marc Tamlyn wrote:
> > I guess now with migrations we have a nice way of running the SQL
> > against the database to create the stored procedures.
> >
> > However if we plan to make this a public API, it s
On Wednesday 22 October 2014 10:50:51 Marc Tamlyn wrote:
>
> As for a work around, using a ChoiceField directly shouldn't be
> particularly difficult in this case. ModelChoiceField has some nice
> features but it is limited.
>
Using a ChoiceField as a substitute for ModelChoiceField isn't hard,
Hi Carl,
On Wednesday 22 October 2014 19:35:49 Carl Meyer wrote:
> On 10/21/2014 04:04 PM, Shai Berger wrote:
> > I'd argue that in the common case, the user shouldn't care if the
> > function they are calling is implemented in Python or Procedural SQL
> > (assumi
On Thursday 23 October 2014 06:14:19 Carl Meyer wrote:
> > On Oct 22, 2014, at 5:56 PM, Shai Berger wrote:
> >> On Wednesday 22 October 2014 19:35:49 Carl Meyer wrote:
> >>> On 10/21/2014 04:04 PM, Shai Berger wrote:
> >>> I'd argue that in the
I agree with Tim completely.
I do see one thing that could help here: Add a check that STATIC_ROOT is not a
subfolder of any app. This check cannot be really reliable (that is, a
particularly careless and unlucky user could set things up so that their
STATIC_ROOT is in an app but the check will
On Thursday 30 October 2014 15:22:01 Dan Poirier wrote:
> Wouldn't enabling this by default cause a problem for any automated
> deploys?
The discussion is about the makemigrations command, not migrate. The OP wants
to use it to find automatically if there are model changes not covered by
migrati
On Thursday 30 October 2014 23:00:18 Andrew Godwin wrote:
>
> If this does happen, I'd probably want some way to declare what defaults to
> keep. (South actually used to have this with a keep_default option on the
> add_column method but it was kind of unmaintained)
>
IIRC, in the few South relea
Hi Everyone,
I just mentioned in another thread that db-level defaults are particularly
troublesome on Oracle. I didn't want to burden that discussion with the
detais, but having been asked about it on IRC (thanks Josh), here they are.
The problem is caused by a combination of factors:
1) Orac
On Tue, 26 Nov 2019 12:28:45 +0100
Maciek Olko wrote:
> It looks like Transifex uses [1] Unicode Language Plural Rules [2].
> If they are incorrect for Hebrew, maybe they should be fixed on
> Unicode side?
>
Just for the record, they are indeed wrong -- not in the sense that has
sparked this th
Hi all,
On Sat, 18 Jan 2020 14:27:23 +0200
Ram Rachum wrote:
> [...] In any case, the
> way Python chains exceptions when showing them is orthogonal to this
> proposed change. Python already displays the exceptions chained even
> if we don't use "raise from", the only thing that "raise from"
> c
On Sat, 18 Jan 2020 17:18:41 +0200
Ram Rachum wrote:
> On Sat, Jan 18, 2020 at 5:05 PM Shai Berger wrote:
>
> > > Regarding automatically enforcing this format going forward: I
> > > looked at the list of Flake8 rules <https://www.flake8rules.com/>
> > &
On Thu, 6 Feb 2020 20:08:28 +0200
Ram Rachum wrote:
>
> If I understand correctly, you both agree that using "raise from" in
> this context is better than using plain raise, just that the benefits
> are not worth the price of a bulk update to Django. In other words,
> "raise from" is the inevita
Hello fellow Djangonauts,
While working on upgrading a project to 2.2, I ran into multiple
instances of
: (admin.E130) __name__ attributes of actions
defined in must be unique.
caused by the fact that, out of a large set of Admin classes, about a
dozen have defined their own ve
Hi Carlton,
On Wed, 18 Mar 2020 17:11:49 +0100
Carlton Gibson wrote:
> I triaged that, and was involved in the change in #29917 that led to
> your issue.
>
> https://code.djangoproject.com/ticket/29917
> https://groups.google.com/d/topic/django-developers/-OWoYL_zryM/discussion
>
Yes, I've se
method on their admin classes without having to
> > resort to redefining .actions which seems to trigger the issue here.
> >
> > Cheers,
> > Simon
> >
> > [0]
> > https://github.com/django/django/blob/d4df5e1b0b1c643fe0fc521add0236764ec8e92a/django/contrib/adm
(sorry about the previous empty mail, UI glitch)
On Wed, 18 Mar 2020 09:29:17 -0700 (PDT)
charettes wrote:
> Just to make the above clear, here's what I had in mind
>
> https://gist.github.com/charettes/a0cb94242ac9c198625b23f4f55fab45
>
Yes, that would do what I want and seems better than my
On Wed, 18 Mar 2020 10:34:30 -0700 (PDT)
charettes wrote:
> I think deleted_selected is *special* since it's the only default
> action provided.
>
I agree, but...
> I guess we could document that a method name string reference should
> be passed to AdminSite.add_action if it's meant to be over
Hi Carlton and all,
I'm not much of a manager, but will be happy to help as much as I can
with technical input.
--
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 recei
I generally sympathize with Collin's position here, but I don't think
deprecation-without-intention-to-remove is a viable option. I think this
discussion is analogous to the Python discussion about the removal of
the ABCs from collections -- they were moved to collections.abc
in 3.3, but a shim was
On Tue, 5 May 2020 14:18:09 -0700
James Bennett wrote:
> On Tue, May 5, 2020 at 2:04 PM Shai Berger wrote:
> > Why? Why is 10 years ok where 7 are not? James' points on this are
> > spot on.
> >
> > Be that as it may, I can see sense in the request for a long
On Tue, 2 Jun 2020 20:57:54 +0200
Aymeric Augustin wrote:
>
> We're talking about a trade-off between preserving optimisations in
> existing code bases and expertise of advanced users versus doing the
> right thing by default for less experienced users.
I disagree.
The suggestion is to make
On Fri, 5 Jun 2020 13:58:47 +0200
Johan Schiff wrote:
> I still think the wrong call was made here [...]
> *(Assuming queryset should be evaluated is probably correct in
> most cases, but sometimes adds a big performance hit when the code
> goes into production and the dataset grows - code that l
Hello,
On Fri, 26 Jun 2020 00:46:02 -0700 (PDT)
Florian Apolloner wrote:
> On Thursday, June 25, 2020 at 7:52:31 PM UTC+2 kit@gmail.com
> wrote:
>
> > Personally, I think that *at minimum* providing Django-builtin "get
> > from env" helpers would be great; beyond that, I'd love to have
> >
Sorry for the bike-shedding, but I think the text should drop the
"using Django" language. The people who come here with these questions
clearly think of themselves as developers, not users.
IMO It should go something like,
Welcome to django-developers, the mailing list for discussion
On Tue, 21 Jul 2020 01:28:31 -0700 (PDT)
Carlton Gibson wrote:
>
> Certainly 99% of cases can be handled as cleanly (or more so, because
> I guess we fell `format()` is a little verbose) with %-formatting or
> an f-string.
> But if we say format() is not allowed, don't we then guarantee we hit
>
Hi Dave and all,
On Tue, 21 Jul 2020 13:56:53 +0100
Dave Vernon wrote:
> More generally:
>
> I understand the value of *not* doing a bulk change in a PR, but I was
> wondering if it's OK to do a PR based purely on improved performance
> for a specific element? (I don't have one in mind, the que
Hi René,
On Tue, 21 Jul 2020 18:46:12 +0200
René Fleschenberg wrote:
> https://github.com/kako-nawao/django-group-by
>
It doesn't actually aggregate, so the name "group-by" seems
unwarranted. What it does, as the README explains, is replace "values"
by something which does two things:
- Sets
AFAIK Postgres, in these cases, simply truncates the name. This means:
1) Generating models with names longer than 63 characters on postgres
is fragile. You may find yourself with more than one model trying to
use the same table name.
2) Suffix-hashing long names like Simon suggests may not be
ba
On Tue, 11 Aug 2020 10:51:58 -0700 (PDT)
charettes wrote:
> > Suffix-hashing long names like Simon suggests may not be
> backwards-compatible.
>
> Could you elaborate on that?
>
> Assuming model names > 100 characters never worked wouldn't only
> suffix-hashing model names > 100 characters
Hi Uri and all,
On Thu, 3 Sep 2020 08:37:42 +0100
Adam Johnson wrote:
> I agree with Florian.
>
Me too.
> The occasional forced logout is probably fine. If you care about this
> enough Uri, you could write a blog post documenting your patch and
> how to use it when upgrading Django.
>
But:
Hi all,
When you define a related field on a model -- a ForeignKey etc -- it
usually adds its related-name as a backwards-accessor on the related
model. These related names are checked for clashes against other fields
and other related-names. But they are not checked for clashes against
other attr
On Sun, 6 Sep 2020 12:01:34 +0100
Adam Johnson wrote:
> I think it would be acceptable to make related name clashes a check
> Error. I'm guessing you couldn't find any justification for why the
> check doesn't currently do this?
>
I didn't find any, though I didn't look too hard.
On the other
Hi,
On Wed, 14 Apr 2021 12:10:56 +0100
"'Adam Johnson' via Django developers (Contributions to Django
itself)" wrote:
> Hi
>
> This seems like a genuine bug, Django should not assume that all
> backends have the same max table name length. Please file a ticket.
>
Right, but it may be a simpl
Hi Nikhil,
I am not calling the shots here, just a member of the community.
However, if you are suggesting this as a work on a 3rd-party library, I
think your suggestion should be either for something completely new, or
a significant improvement over existing 3rd-party libraries. Libraries
which
Hi Aditya,
I think the basic issue is that the DB Routers framework is not the
right tool for the task you have in mind. You are trying to redirect
all database activity according to request parameters. The routers are
built for specific uses, and -- by design -- they don't cover all
cases; it's n
On Wed, 12 May 2021 09:37:53 -0700 (PDT)
"'Mike Lissner' via Django developers (Contributions to Django
itself)" wrote:
>
> I haven't done the manual approach but I imagine it's something like:
>
> 1. Check your migrations across all apps with interdependencies for
> RunPython or RunSQL code.
Just to clarify the use-case:
Why is a before-commit signal preferable to a vanilla Python
context-manager around the code? Or, if it is in the context of
requests, a middleware?
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to D
Hi Raphael,
On Tue, 12 Oct 2021 11:28:20 +0200
Raphael Michel wrote:
> In our case, "not using savepoint rollbacks any more" would be a
> trade-off that we'd happily make (there are enough other problems
> with savepoints to begin with)
You seem to imply that savepoint rollbacks are a very easy
On PG we can and should do much better -- there is a way to get a very fast,
though not accurate, count of records in a table:
https://wiki.postgresql.org/wiki/Count_estimate
I think we should expose an API along the lines of
queryset.table_count(estimate_above=2000)
which act
On Wednesday 09 August 2017 00:40:30 Josh Smeaton wrote:
> We use the explain analyze method at work, but I don't think it's an
> appropriate thing to include in core.
>
Agreed.
> I'm not so sure about providing count estimates in core, but I don't fully
> grok how the `estimate_above` would wor
First of all, I think making the auto-prefetch feature available in some form
is a great idea. As an opt-in, I would have made use of it on several
occasions, and cut days of optimization work to minutes. It's true that this
wouldn't achieve the best possible optimization in many cases, but it w
On Friday 18 August 2017 09:08:11 Anssi Kääriäinen wrote:
> Maybe we should just add the queryset method. This is the smallest atomic
> task that can be done. Even if there's only the queryset method available,
> it's possible to enable prefetches per model by using a Manager.
>
I disagree on both
On Monday 21 August 2017 18:44:35 Tobias McNulty wrote:
> On Sat, Aug 19, 2017 at 1:10 PM, Luke Plant wrote:
> > This could work something like the way that ForeignKey `on_delete` works
> > - you have options that are enumerated as constants, but in reality they
> > are classes that embody the str
I think that giving this funcionality names that follow the patterns of
select_related() or prefetch_related() is bad, because although it is very
close to them in subdomains (dealing with relations), its functionality is
much closer to annotate(). In particular, alias is better than to_attr bec
I would like to add to this discussion just the clarification that, when we say
Django relies on transactions, we don't mean that it is impossible to write a
database backend which doesn't implement them -- but that Django assumes
transactional behavior to protect data integrity. It can work wit
ove this,
> it currently monkey patches connection.ops.last_executed_query to listen to
> all the queries going on.
>
> On 7 April 2017 at 16:10, Shai Berger wrote:
> > On Friday 07 April 2017 17:47:51 Carl Meyer wrote:
> > > Hi Shai,
> > >
> > > On 04/0
On Friday 15 September 2017 11:09:58 Anssi Kääriäinen wrote:
> Would it make sense to use the same technique used for HTTP
> request/response middleware? That is, the hook would look a bit like this:
>
> def simple_execute_hook(execute):
> # One-time configuration and initialization.
> def
On Friday 15 September 2017 11:35:49 Shai Berger wrote:
> On Friday 15 September 2017 11:09:58 Anssi Kääriäinen wrote:
> >
> > def simple_execute_hook(execute):
> > # One-time configuration and initialization.
> >
> > def execute_hook(sql, params, m
Can we define a new API on the permission backend, "verify_permission_exists()"
or some such, and just call it if settings.DEBUG and it is provided? That
doesn't seem very complex to me, and doesn't necessarily imply a huge
performance hit (even in DEBUG).
On Thursday 28 September 2017 15:50:04
Hi Jay,
First, I'd like to say that your post was very nicely done. You did not miss
any conventions as far as I could see. I believe the only reason you got no
responses so far is that the issue is relatively fringe, and your message was
relatively long.
For the subject matter, though, it see
I can see the problem as well, and I can see it in 2.0 and 1.11 too. Please
open a new bug on the testing framework.
On Monday 09 October 2017 06:50:15 Shun Yu wrote:
> When I try to run the whole test suite it works fine, it's just that when I
> try to run this specific one it's failing on me.
>
On Thursday 16 November 2017 07:21:38 Josh Smeaton wrote:
>
> I don't agree with reimplementing lookups/transforms/funcs to produce the
> python version of a SQL concept. It's a leaky abstraction. Instead, I'd
> prefer the model author provides their python calculation:
>
> is_adult = models.
On Friday 17 November 2017 15:53:10 sevenrrain...@gmail.com wrote:
> I’m sorry, desperate move, because I couldn’t find any proper channel for
> this.
>
>
> Can you guide me to a proper channel that can answer my question, besides
> the ones above.
>
If you cannot find an answer on the public c
On Thursday 16 November 2017 14:08:20 Sjoerd Job Postmus wrote:
> I disagree with not being able to calculate it locally (without the
> database): such a calculation depends on other fields. What if a dependent
> field is updated, but the object is not yet saved. What should the value
> be?
>
> >>
On Saturday 18 November 2017 15:06:20 Shai Berger wrote:
>
> 1) Make all computations in Python. This means the feature can be supported
> only on databases which can run Python as part of their queries; I'm not
> quite sure about the details, but I think PG can. I'm certa
On Saturday 18 November 2017 21:32:47 ilya.kazakev...@jetbrains.com wrote:
> > Such computations always end up slightly different in some
> > edge cases
>
> I agree.
> We can document this fact. Model authors should be aware that they are not
> allowed to use anything but literals. All other funct
401 - 500 of 645 matches
Mail list logo
