I'm a bit confused how multi-threading has anything to do with AJAX?
Your requests will be slower, but they will still get processed (at
least I've never had any issues).
On Nov 16, 1:03 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
wrote:
> If the patch that's currently on there works with no chan
On Nov 16, 6:26 am, Chris <[EMAIL PROTECTED]> wrote:
> I thinkhttp://code.djangoproject.com/ticket/3357should be given
> another look at enabling optional multi-threading on the dev server.
>
> Jacob previously closed this ticket, noting the patch could introduce
> threading bugs, and would prov
Some months ago I tried a snippet from djangosnippets.org which shows a
upload progress bar. I think some people want to use snippets like that and
a multi-threaded server would help you developing such applications.
2008/11/16 Vinay Sajip <[EMAIL PROTECTED]>
>
>
>
> On Nov 16, 6:26 am, Chris <[E
Julian wrote:
> [...] I think some people want to use snippets like that [...]
Wouldn't you agree that's a pretty feeble use case for something as
potentially disruptive as multi-threaded serving? Particularly when the
CherryPy alternative is so readily available.
regards
Steve
--
Steve Holden
> (and obviously I meant 'setup.py sdist')
>
I don't know how setup.py bundles a tarball, but it's doing it wrong
-- GeoDjango is broken in the 1.0.1 release tarball. In particular,
at least the following directories were completely _omitted_ from this
release:
http://code.djangoproject.com/bro
On Nov 16, 2008, at 15:37, Justin Bronn wrote:
> http://code.djangoproject.com/browser/django/branches/releases/1.0.X/django/contrib/gis/templates
> http://code.djangoproject.com/browser/django/branches/releases/1.0.X/django/contrib/gis/tests/geoapp/sql
>
> While the missing test data is OK, not
> The reason is that MANIFEST.in doesn't tell setuptools to include those
> directories in the distribution.
Thanks, I eventually figured this out on my own -- it was the
problem. Fixed in r9473 and r9474.
-Justin
--~--~-~--~~~---~--~~
You received this message b
On Sun, Nov 16, 2008 at 1:26 AM, Chris <[EMAIL PROTECTED]> wrote:
>
> I think http://code.djangoproject.com/ticket/3357 should be given
> another look at enabling optional multi-threading on the dev server.
> 3. Fear of multi-threading bugs shouldn't be a reason to avoid multi-
> threading, espec
@#$%!.will this composite primary key feature be included in
Django 2.0? Or will this be ever included? Let me explain my
frustration a bit.
My company only allows Oracle db and the legacy tables span hundreds
of schemas and hundreds of tables in each schema, in multiple
databases. This limit
>>> Well, what are those features you wanted, explicitly?
>>
>> Mostly what has been written down
>> athttp://code.djangoproject.com/wiki/InstalledAppsRevision
>
> Thank you for your response. If you mean
>
>* Allow change of name of third-party app
>* Allow change of db_prefix of third-p
On Sun, Nov 16, 2008 at 2:42 PM, Frank Liu <[EMAIL PROTECTED]> wrote:
>
> @#$%!.will this composite primary key feature be included in
> Django 2.0? Or will this be ever included? Let me explain my
> frustration a bit.
>
>
[snipped]
Did I miss something? Your note makes it sound like the cor
On Nov 16, 7:48 pm, Jannis Leidel <[EMAIL PROTECTED]> wrote:
> >>> Well, what are those features you wanted, explicitly?
>
> There was a case for multiple instances of apps when it was discussed
> at the Pycon sprint and I just forgot it.
>
Ok - I'm not saying there's no case for it, just that
On Nov 16, 5:21 pm, "Waylan Limberg" <[EMAIL PROTECTED]> wrote:
> On Sun, Nov 16, 2008 at 1:26 AM, Chris <[EMAIL PROTECTED]> wrote:
> Especially considering there are already working solutions out there.
> I seem to recall at least one management command someone put together
> that runs a multit
i just implemented something like this. it useses decorator-syntax
to create a denormalized field from a callable.
i think the advantages of this aproach are:
1) it's very flexible
2) all code related to the denormalisiation is located in one central
place,
and not one place for the field definiti
I guess i thought the core developers would've added this proposal to
the list (judging from the title of this thread).
Regardless, even if this had been added, it would've been given a -1
anyway, judging from the readiness of this feature.
More importantly though, my gripe about this is that if
Frank Liu wrote:
> I guess i thought the core developers would've added this proposal to
> the list (judging from the title of this thread).
>
> Regardless, even if this had been added, it would've been given a -1
> anyway, judging from the readiness of this feature.
>
> More importantly though, m
Hi Frank --
It's hard for me to figure out how to answer this: if you've got a
problem with my leadership skills, I don't really see how anything I
say makes much of a difference. Frankly, your tone is completely
inappropriate and I feel I'm enforcing absurdly out-of-line behavior
simply by respo
> Thanks, I eventually figured this out on my own -- it was the
> problem. Fixed in r9473 and r9474.
>
I wish I had known about MANIFEST.in sooner, is there any way we re-
tag and re-release 1.0.1 with the missing files? Or am I forced to
instruct GeoDjango users to avoid easy_install until 1.0.
Also keep in mind that work has been done, but as I haven't had a lot of
spare time to continue it (attempt #3?). It's a very complex problem as
well, like Jacob mentioned. You have to deal w/ the legacy use of single
primary keys, as well as the new composites. While I almost have a fully
function
On Sun, Nov 16, 2008 at 5:19 PM, David Cramer <[EMAIL PROTECTED]> wrote:
> Also keep in mind that work has been done, but as I haven't had a lot of
> spare time to continue it (attempt #3?). It's a very complex problem as
> well, like Jacob mentioned. You have to deal w/ the legacy use of single
>
On Sun, Nov 16, 2008 at 6:07 PM, Justin Bronn <[EMAIL PROTECTED]> wrote:
>
> > Thanks, I eventually figured this out on my own -- it was the
> > problem. Fixed in r9473 and r9474.
> >
>
> I wish I had known about MANIFEST.in sooner, is there any way we re-
> tag and re-release 1.0.1 with the miss
On Sun, Nov 16, 2008 at 5:33 PM, Karen Tracey <[EMAIL PROTECTED]> wrote:
> The other alternative is building 1.0.2 from 'traditionally' from the
> current 1.0.X branch contents. So 1.0.2 would have a handful of fixes in
> addition to the missing gis files. The fixes that have gone in are small &
http://github.com/dcramer/django-compositepks/tree/master#
On Nov 16, 5:25 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> On Sun, Nov 16, 2008 at 5:19 PM, David Cramer <[EMAIL PROTECTED]> wrote:
> > Also keep in mind that work has been done, but as I haven't had a lot of
> > spare time to c
Hi Jacob,
Let me apologize first for using JKM as an alias to the whole core
team. I guess the problem here is that adding this feature really
entail changes in too many areas. It would be nice if you and the
other core team members can set a direction for changes on this issue.
The various patch
So far it allows declaration and creation of primary key models. You
declare them in class Meta: primary_key = ('field', 'field', 'field').
There is no ForeignKey/Relational? handlers as of right now, but the
admin is mostly working.
Alex Gaynor pointed out there is one unrelated change I accide
On Sun, Nov 16, 2008 at 5:50 PM, David Cramer <[EMAIL PROTECTED]> wrote:
> http://github.com/dcramer/django-compositepks/tree/master#
Cool; I'll take a look tomorrow. Do you want me to make changes in my
own tree, or would you rather patches back to you?
Jacob
--~--~-~--~~--
> I didn't know MANIFEST.in needed data directories listedI know from bug
> fixing in setup.py that it generates a list of data files to pass into setup
> -- I wonder what that is used for? I guess it's for install but not
> distribution tarfile building?
Neither did I -- and those files _ar
I think forking it on github would be the best. I really like how easy it
makes things.
There's still quite a bit that will need done, mostly with code cleanup, and
tests, but I think it will give everyone a pretty good start.
If you'd like I can give you just direct commit access to the branch a
On Sun, Nov 16, 2008 at 5:42 PM, Jacob Kaplan-Moss
<[EMAIL PROTECTED]> wrote:
> I'll defer to James to make the final call, but I'd prefer to do this
> and release 1.0.2 on Monday or Tuesday with a note that it's basically
> 1.0.1 plus the GeoDjango stuff we forgot and a couple of new bug fixes
>
On Sun, 2008-11-16 at 15:55 -0800, Frank Liu wrote:
> Hi Jacob,
>
> Let me apologize first for using JKM as an alias to the whole core
> team. I guess the problem here is that adding this feature really
> entail changes in too many areas. It would be nice if you and the
> other core team members
>>> If the basic premise of an app class - instances of which can
>>> live in
>>> settings.INSTALLED_APPS - is acceptable (and, of course, this means
>>> instances of subclasses of app can live in settings.INSTALLED_APPS
>>> too) then the precise location of an implementation (e.g.
>>> django.c
On Sun, 2008-11-16 at 17:42 -0600, Jacob Kaplan-Moss wrote:
> On Sun, Nov 16, 2008 at 5:33 PM, Karen Tracey <[EMAIL PROTECTED]> wrote:
> > The other alternative is building 1.0.2 from 'traditionally' from the
> > current 1.0.X branch contents. So 1.0.2 would have a handful of fixes in
> > additi
This: http://code.djangoproject.com/ticket/9613 seems to be of the
same vein. I haven't confirmed it however.
On Nov 16, 7:54 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Sun, 2008-11-16 at 17:42 -0600, Jacob Kaplan-Moss wrote:
> > On Sun, Nov 16, 2008 at 5:33 PM, Karen Tracey <[EMAIL
On Mon, 2008-11-17 at 01:50 +0100, Jannis Leidel wrote:
> >>> If the basic premise of an app class - instances of which can
> >>> live in
> >>> settings.INSTALLED_APPS - is acceptable (and, of course, this means
> >>> instances of subclasses of app can live in settings.INSTALLED_APPS
> >>> too
Hi all,
I've been playing with adding sqlite3 back-end support to GeoDjango,
using the SpatiaLite extension. This requires executing some magic
SQL each time you connect to the database, to enable the spatial
extensions. Ticket #6064 seems like this right way to do this, by
causing the
PsycoPg2 with a remote DB over a WAN is deadly slow. Since PsycoPg2
supports connection pooling, I have decided to patch the Django DB
adapter to use this. I could see this implemented as below (this is a
very rough draft). For example, min and max connections should not be
hardcoded.
Let me know
This sounds like a good feature, however, it's very difficult to read
a patch in either email or on google groups, so could you please open
a ticket in trac, and post this as a patch there.
On Nov 16, 2:57 pm, jothan <[EMAIL PROTECTED]> wrote:
> PsycoPg2 with a remote DB over a WAN is deadly slow
I think I may have to actually agree that multi-threading is somewhat
needed, since it does limit these kind of features from working. I,
however, would deem it less a priority than most thing. If you can
write a patch for it (or if one exists, I didn't look) though, I don't
see any reason to not
On Sun, 2008-11-16 at 11:57 -0800, jothan wrote:
> PsycoPg2 with a remote DB over a WAN is deadly slow. Since PsycoPg2
> supports connection pooling, I have decided to patch the Django DB
> adapter to use this. I could see this implemented as below (this is a
> very rough draft). For example, min
On Sun, 2008-11-16 at 17:14 -0800, Matthew D. Hancher wrote:
> Hi all,
>
> I've been playing with adding sqlite3 back-end support to GeoDjango,
> using the SpatiaLite extension. This requires executing some magic
> SQL each time you connect to the database, to enable the spatial
> extensi
In terms of signal overhead, the most likely case here is probably no
receivers, and in the signal refactor, that particular case is now
hugely faster.
On Nov 16, 8:55 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Sun, 2008-11-16 at 17:14 -0800, Matthew D. Hancher wrote:
> > Hi all,
>
>
On Sun, 2008-11-16 at 18:11 -0800, [EMAIL PROTECTED] wrote:
> In terms of signal overhead, the most likely case here is probably no
> receivers, and in the signal refactor, that particular case is now
> hugely faster.
"Hugely" being, of course, a highly scientific measurement lending
itself to a
On Mon, Nov 17, 2008 at 11:20 AM, Malcolm Tredinnick
<[EMAIL PROTECTED]> wrote:
>
>
> On Sun, 2008-11-16 at 18:11 -0800, [EMAIL PROTECTED] wrote:
>> In terms of signal overhead, the most likely case here is probably no
>> receivers, and in the signal refactor, that particular case is now
>> hugely
> This:http://code.djangoproject.com/ticket/9613seems to be of the
> same vein. I haven't confirmed it however.
Yeah I confirmed it. I went through the contrib apps one-by-one to
see if anything else was missing. In addition to auth's missing
files, the templates for formtools are omitted.
I'
On Sun, 2008-11-16 at 18:42 -0800, Justin Bronn wrote:
> > This:http://code.djangoproject.com/ticket/9613seems to be of the
> > same vein. I haven't confirmed it however.
>
> Yeah I confirmed it. I went through the contrib apps one-by-one to
> see if anything else was missing. In addition to
Well, Jeremy Dunck was kind enough to do a benchmark against the old
system:
http://groups.google.com/group/django-developers/browse_thread/thread/815f76ad7e823cbf/b008a757fbdefa2b
On Nov 16, 9:49 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> On Mon, Nov 17, 2008 at 11:20 AM, Malcolm
On Sun, 2008-11-16 at 19:21 -0800, [EMAIL PROTECTED] wrote:
> Well, Jeremy Dunck was kind enough to do a benchmark against the old
> system:
> http://groups.google.com/group/django-developers/browse_thread/thread/815f76ad7e823cbf/b008a757fbdefa2b
Since we're no longer using the old system, that
On Mon, Nov 17, 2008 at 12:21 PM, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
>
> Well, Jeremy Dunck was kind enough to do a benchmark against the old
> system:
> http://groups.google.com/group/django-developers/browse_thread/thread/815f76ad7e823cbf/b008a757fbdefa2b
I knew about these. While th
Right, I understand the need for absolute numbers, I just meant that
we don't need to start rewriting new benchmarks if Jeremy still has
the benchmark script.
Alex
On Nov 16, 11:03 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> On Mon, Nov 17, 2008 at 12:21 PM, [EMAIL PROTECTED]
>
> <[EM
What is the big deal? I was on a gig recently where Django was used
with Oracle. To support model partitioning for selected models, we
munged the generated SQL for model creation to add composite keys and
the partitioning logic. It was a little bit hairy, but once the model
creation was correct, e
50 matches
Mail list logo
