Hi,
I've made some work on https://code.djangoproject.com/ticket/16455 and I
think I'm close to have it ready for checking.
Can I have a quick review from the committers? I'm mostly interested in
feedback about:
* the v8 patch installs multidimensional index for columns with more than 2
dimen
alternative.
>
> It's hard for me to assess the patch w/o some more context re. the
> upstream postgis changes.
>
> On Wed, Aug 8, 2012 at 8:12 AM, Flavio Curella
> >
> wrote:
> > Hi,
> >
> > I've made some work on https://code.djangoproj
I was running the wrong query for the 3D case.
I've updated the benchmark gist and added some test under PostGIS 1.5.
On Thursday, August 9, 2012 4:03:45 PM UTC-5, Anssi Kääriäinen wrote:
>
> On 9 elo, 23:48, Jeremy Dunck wrote:
> > I'm fairly familiar with the django gis code, but I haven't bee
think we should create the index for 2D case, just as we did on PostGIS
1.5.
Re: the 3D case, 2) brings the question: should we add these new operators?
Is it out of scope for the ticket?
On Thursday, August 9, 2012 4:18:48 PM UTC-5, Flavio Curella wrote:
>
> I was running the wrong query
:00:43 PM UTC-5, jdunck wrote:
>
> On Thu, Aug 9, 2012 at 2:42 PM, Flavio Curella
> >
> wrote:
> > From the benchmark, my understanding is that, on PostGIS 2.0:
> >
> > 1) for the 2D case, the best index is 'gist (columname)'
> > 2) fo
Thanks everyone for the feedback on this patch.
I've added some code that deals with database creation. Specifically, to
support the template database approach also on PostGIS 2.
I still have some failing test, but they fail on both PostGIS1.5 and 2.0.
I'm running ``./runtests.py --settings= gi
I've fixed the tests and they pass under postgres9.1+postgis1.5
On Friday, August 24, 2012 10:21:08 AM UTC-5, Flavio Curella wrote:
>
>
> Two of the failures are:
>
> AssertionError: u'{ "type": "Point", "coordinates": [ 100.0
I'm not sure if this warrants a DEP, so I've decided to post it to the list
first. If this needs to be a DEP, just let me know and I'll follow the DEP
process.
Rationale
-
Assume the following scenario:
1. At some point in history, project A was deployed in production and was
very
to handle this and similar scenario. The goal
of my proposal was to enable a more convenient way.
>
> /Markus
>
> On September 19, 2015 6:38:59 AM GMT+10:00, Flavio Curella <
> flavio@gmail.com > wrote:
> >I'm not sure if this warrants a DEP, so I'
On Saturday, September 19, 2015 at 8:39:54 AM UTC-5, Shai Berger wrote:
>
> Hi,
>
> On Saturday 19 September 2015 14:02:38 Markus Holtermann wrote:
> > On September 19, 2015 6:38:59 AM GMT+10:00,
> > Flavio Curella > wrote:
> > >
> > >
icket about intcomma or about a new
filter in humanize.
Thanks,
Flavio Curella.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-
sorry, wrong snippets
```
# assume years_range = range(2008, 1900)
formfield_overrides = {
'body': { 'widget': RichTextEditorWidget() },
'birthday': {'widget': SelectDateWidget(years=years_range) },
}
```
maybe this is for yet another option, or we can allow something like
this (ps: i do
hi,
I read the patch in #8306, and looks like formfield_overrides allows
to change the default widget only on a field type basis:
```
formfield_overrides = {
models.TextField: {'widget': RichTextEditorWidget},
}
```
Wouldn't it be more granular to allow the overrides on the field name
basis
I just want to clarify a few misunderstanding that I keep seeing popping up.
1. If you read the original
ticket, https://code.djangoproject.com/ticket/22667 you will notice that my
original concern wasn't the word 'master', nor the word 'slave', but the
usage of both terms together. What basica
Hi y'all,
One of the most common performance issues we found with our clients is the
"n+1 queries" problem: some code will access some related objects of an
instance that's been fetched without `select_related` or `prefetch_related`.
There are many way this can be improved[1] from the user side
`assertNumQueries` is useful in *preventing* accidental N+1 in your views,
and I sure which people would use a lot more.
But there are many situations where a N+1 can get created and people
usually have don't write tests for (even if they should have). For example,
assume this model:
```
# mod
On Tuesday, May 28, 2019 at 11:48:11 AM UTC-5, James Bennett wrote:
>
>
> I guess my question is: if your devs won't check this in tests, why do you
> expect they'll check it through another mechanism? :)
>
I don't expect them to. The logging is for me, the consultant hired to find
why their co
I'm thinking about adding support for `Q` to `get_or_create` and
`update_or_create`. I've summarized my thoughts at
https://code.djangoproject.com/ticket/27070.
I have a couple of unsolved question; the most critical is the one Tim
raises: if we were to add another keyword argument to those m
kwarg name to specify the
> query
> object the `(get|update)_or_create` APIs would end up disgressing from the
> `filter()`
> and `get()` ones which is the main objective of this proposed change I
> beleive.
>
> Simon
>
> Le mardi 16 août 2016 13:57:25 UTC
I'd like to take another try at this.
My proposal is to temporarily supports two formats: the new
`app_label.model_name.codename` (ref #25281) and the old `app.codename`.
The old format will raise a PendingDeprecationWarning. Docs, code and tests
will be updated to use the new format.
I belie
Symbols?
On 29 Mag, 09:47, simonbun <[EMAIL PROTECTED]> wrote:
> Hmm, policy reminds me of a few pages of text with legal mumbo jumbo,
> like an acceptable use policy.
>
> We can go for something technical, like values, properties, entries,
> constraints, presets, ... or maybe it's time for somet
http://groups.google.it/group/django-users
On 4 Giu, 01:29, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
wrote:
> Ah Ok.
>
> Do you have a link to that group ?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django dev
22 matches
Mail list logo
