On Tuesday, March 26, 2013 10:47:34 PM UTC+1, Petite Abeille wrote:
>
>
> On Mar 26, 2013, at 10:03 PM, Alex Gaynor >
> wrote:
>
> > For what it's worth, SQL2011 does define OFFSET, finally.
>
> Perhaps worthwhile mentioning as well :
>
> "Do not try to implement a scrolling window using LIMI
On 27 mars 2013, at 09:10, Stefano Crosta wrote:
> it would be great to see server-side cursors and/or a smarter way to iterate
> make it into core.
FYI this topic is tracked here: https://code.djangoproject.com/ticket/16614
--
Aymeric.
--
You received this message because you are subscr
On 27 maalis, 10:10, Stefano Crosta wrote:
> On Tuesday, March 26, 2013 10:47:34 PM UTC+1, Petite Abeille wrote:
>
> > On Mar 26, 2013, at 10:03 PM, Alex Gaynor >
> > wrote:
>
> > > For what it's worth, SQL2011 does define OFFSET, finally.
>
> > Perhaps worthwhile mentioning as well :
>
> > "Do no
Thanks Aymeric,
that's true, and I should have put that link too.
sadly "akaariai" who's the only one who seemed to understand a bit about it
(and is a core dev) did not seem interested in bringing this any forward,
so I thought I'd try to raise some interest again!
On Wednesday, March 27, 2013
On 03/27/2013 10:53 AM, Stefano Crosta wrote:
Thanks Aymeric,
that's true, and I should have put that link too.
sadly "akaariai" who's the only one who seemed to understand a bit
about it (and is a core dev) did not seem interested in bringing this
any forward, so I thought I'd try to raise som
Thanks Anssi for both your replies. These db interactions definitely are
really beyond the scope of my knowledge, unluckily.
I did try and implement an iterator such as the one that you describe in
your other message, based on index column filtering - what I dislike is
that it's an additional f
Hi all.
Can anyone tell, does django.cache locks file for writing by concurrent
process?
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+
For what it's worth I'd be against this proposal as it stands.
* I haven't seen anything anything that convinces me that a single wrapping
view isn't a reasonable alternative in the examples cited.
* A `UrlNotMatched` exception sounds like the potential source of
incredibly non-obvious bugs and
You've already asked this on django-users. Django-developers is for
discussing the development of Django itself -- it shouldn't be used as
"second tier" support if you don't get the answer you want on django-users.
Yours,
Russ Magee %-)
On Wed, Mar 27, 2013 at 8:16 PM, Ivan wrote:
> Hi all.
> C
Hi Tom, interested to see why you think a single wrapping view is a
reasonable alternative for the example I showed above, where you have
following list of URLs:
// # front page for country
// / # list of schools and companies with activities in
that industry, in that country
/// # list of ind
Yes, you are right. But I asked for another reason.
For example, I see, that werkzeug's cache write cache trough temporary file
https://github.com/mitsuhiko/werkzeug/blob/master/werkzeug/contrib/cache.py#L660
But Django cache do not use neither, tmp file or file locking.
So, multiple processes ca
Tom, you're right about the second and third points though. If the user
perform any operation with side effect that requires writing to the
database before the view checks whether the keyword arguments are
appropriate and decide to raise DoesNotResolve, it can definitely be a
source of non-obvi
Hey all,
I'm working on adding that pre_syncdb signal, I've come across a
rother peculiar detail. When I import django.db.signals, it maps to
django.core.signals. Am I missing something here? I know for example,
django.conf generates the settings import. Can someone point me to tho
logic o
On Thu, Mar 28, 2013 at 7:13 AM, Ivan wrote:
>
> Yes, you are right. But I asked for another reason.
> For example, I see, that werkzeug's cache write cache trough temporary
> file
> https://github.com/mitsuhiko/werkzeug/blob/master/werkzeug/contrib/cache.py#L660
> But Django cache do not use nei
I'm not sure what you mean by "maps to".
The basic signal framework is in django.dispatcher. If you're
implementing https://code.djangoproject.com/ticket/11398 then you
probably want to import: from django.dispatcher import Signal.
django.db imports django.core.signals because it is a *consumer*
> As I said in my response on django-users, the file based...
-- Oh, I didn't see it yet. Thanks.
> if you want to try your hand at a patch, this should be a relatively
simple patch to create (although tests could be a little bit complex).
-- yes, it's a good idea, but i need first to study the
Hi Joseph,
There's no logic that does any such thing. There's nothing unusual or
Django-specific going on here - it's just how Python imports work.
There is a module called django.core.signals. It contains the definitions
for a bunch of signals related to the core operation of Django, like the
'c
With ATOMIC_REQUESTS, after cache invalidation, the concurrent process can
re-create cache old data, between deleting of cache and commit.
Perhaps this problem should be solved by repeat cache deleting after commit.
--
You received this message because you are subscribed to the Google Groups
"
18 matches
Mail list logo
