Slicing is cool, but I'm +1 for deprecating it and using .limit().
Slicing in my mind should return an iterable and you shouldn't be
messing w/ properties on that iterable, even though somethings you
might want to.
For example:
We extend the queryset model for our fulltext search -- which uses
s
read this first:
http://www.davidcramer.net/code/61/handling-cache-invalidation.html
The goal is to create a cachedmodel, which relies on a completely
different set of routines. All calls to this model, whether it be a
foreignkey lookup, an objects call, or a JOIN on it's table (inside
the ORM),
ll).
This is just a quick write up the basic CachedModel (which in no way
will work w/o modifying Django). It should give a general of the idea.
On Dec 6, 2:46 pm, David Cramer <[EMAIL PROTECTED]> wrote:
> read this
> first:http://www.davidcramer.net/code/61/handling-cache-invalidation.
We briefly discussed adding row-level dependencies (this key is
dependent on x, y and z keys. It would be handled by storing an extra
object in memory that stored the dependencies for the object. A simple
reverse mapping if you will.
e.g.
- articles_article:1 has the object cache for the article
> > We briefly discussed adding row-level dependencies (this key is
> > dependent on x, y and z keys. It would be handled by storing an extra
> > object in memory that stored the dependencies for the object. A simple
> > reverse mapping if you will.
>
> The intention here would be to handle insert
We ran into the problem lately, that we wanted to integrate our new
authentication services into an authentication backend. Too bad for us
that we can't set cookies or responses inside of authenticate().
Here's a potential solution that we are considering implemented. This
is untested code, I jus
k" <[EMAIL PROTECTED]> wrote:
> On Dec 13, 2007 11:14 AM, David Cramer <[EMAIL PROTECTED]> wrote:
> ...
>
> > > Since inserts are undetected by the cache in the basic proposal, are
> > > you accepting only short timeouts? I imagine with your traffic, eve
Oh, for the record, authenticate() still won't work for us, because
now we don't have the request object :P
On Dec 13, 3:22 pm, David Cramer <[EMAIL PROTECTED]> wrote:
> We ran into the problem lately, that we wanted to integrate our new
> authentication services into an
Upon further discussion -- there may be an easier solution is just
overloading the setattr on request.COOKIES and setting those in a
response middleware.
On Dec 13, 3:25 pm, David Cramer <[EMAIL PROTECTED]> wrote:
> Oh, for the record, authenticate() still won't work for us, be
Let me start by saying I haven't read over this entire post (only
briefly on the initial thread).
For messages, why not switch these to using sessions? We have
implemented anonymous (on-demand) sessions locally, it could be very
useful to do this in general.
On Dec 19, 8:51 am, David Danier <[EM
I'm going to be updating the project page with as much bad English as
I can possibly write :)
If anyone else is interested in contributing the project please let me
know.
On Dec 19, 8:33 pm, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote:
> Here's the IRC chat from today:
>
> Most useful bits:
>
> dja
We have finalized our middleware to handle this. (http://
www.davidcramer.net/code/62/set-cookies-without-a-response-in-django.html)
I'm not sure all developers point of view on this, but if there's
enough interest I'll create a ticket/patch for it.
On Dec 13, 3:52 pm, David
This is something we could really use.
I'm assuming to access those attributes they're just appended on the
new objects created?
So I could have:
MyModel():
relationships = models.ManyToManyField(ContentType,
through="Relationship")
Relationship():
content_type = models.ForeignKey(Cont
ul
> for setting properties on _relationships_ between models, instead of
> setting them on models themselves. Plus, explicit is better than
> implicit :)
>
> Thanks,
> Eric Florenzano
>
> On Dec 22, 1:14 pm, David Cramer <[EMAIL PROTECTED]> wrote:
>
>
I was looking over some code today and noticed that the __new__
definition of ModelBase does if x in dir(y). Doing some quick tests
showed this was a lot slower than doing if hasattr(x, y). Is there any
reason it's done like this?
http://www.pastethat.com/Qxayj
This is the specific group of line
With the latest trunk I actually had 4 unit test failures -- maybe my
setup is screwed. http://www.pastethat.com/VulU5
These happened either way though, the same errors.
On Dec 23, 9:03 pm, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> On Dec 23, 2007 8:02 PM, David Crame
Any reason it's not the default?
On Dec 24, 12:31 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Sun, 2007-12-23 at 23:47 -0800, David Cramer wrote:
> > With the latest trunk I actually had 4 unit test failures -- maybe my
> > setup is screwed.http://www.paste
So it seems I'm finally to the point of where the code is working as
intended, at least for the initial phase.
Anyways, I had some weird quirks, and I don't know Django internals as
well as I'd like. I'd like to request anyone interested in the
project, or with some spare time, take a quick glanc
Project link is probably useful: http://code.google.com/p/django-orm-cache/
:)
On Jan 21, 4:10 pm, David Cramer <[EMAIL PROTECTED]> wrote:
> So it seems I'm finally to the point of where the code is working as
> intended, at least for the initial phase.
>
> Anyways, I had
In fact, here's a shinier post with updated tests:
http://www.davidcramer.net/code/73/caching-layer-for-django-orm.html
On Jan 21, 4:10 pm, David Cramer <[EMAIL PROTECTED]> wrote:
> Project link is probably useful:http://code.google.com/p/django-orm-cache/
> :)
>
> On
You can either use MyModel.nocache, or use MyModel._default_manager (I
had been using the latter)
On Jan 21, 6:09 pm, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote:
> On Jan 21, 2008 4:10 PM, David Cramer <[EMAIL PROTECTED]> wrote:
>
>
>
> > So it seems I
articles because the dataset changed.
If you understand by gibberish, tell me what you think
On Jan 21, 6:19 pm, David Cramer <[EMAIL PROTECTED]> wrote:
> You can either use MyModel.nocache, or use MyModel._default_manager (I
> had been using the latter)
>
> On Jan 21, 6:09 pm,
I plan to attend, and I may be able to stay for the sprints this year.
Model inheritance is much on my wants list as well.
On Jan 25, 4:04 pm, "Tom Tobin" <[EMAIL PROTECTED]> wrote:
> Over at The Onion, we're working on a major new project in Django.
> (By "major", well, let's just say that it do
thods/organization behind it
could use a 2nd opinion though.
On Jan 25, 10:19 pm, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote:
> On Jan 23, 2008 7:35 PM, David Cramer <[EMAIL PROTECTED]> wrote:
>
>
>
> > Some notes I shoved into a commit today:
> ...
>
> > If
I'm with Ivan. If QSRF supports everything we do + everything we want,
there's no need for args (as theres no need for custom queries), but
until it does, *args is very valuable, or at least a method which can
do the same.
On Jan 29, 1:43 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> On 1/
I somehow can't see the custom_query solving our issues with needing
custom queries. How is it going to handle JOINs?
On Feb 2, 4:06 pm, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> On Jan 29, 2008 2:13 PM, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
>
> > I'd like to deprecate initializing mo
We've had many interesting situations come up with newforms where we
couldn't use the simple form.as_p method.
Myself, being the lazy person I am, use form.as_p anywhere possible.
We've even modified it to spit out class names based on widget type.
What I'd like to propose (and hear a good reaso
Why don't they provide settings for MySQL, PostgreSQL, Oracle, MSSQL,
etc?
On Feb 12, 5:47 am, "Waldemar Kornewald" <[EMAIL PROTECTED]>
wrote:
> Hi,
> when I tried to run Django's unit tests I faced a little problem: it
> wanted me to create a settings file. Why don't you provide a fallback
> tes
Per my patches and what I believe Malcom has done with qsrf, the
syntax for related fields was field__related__name, and yes, you would
repeat this over and over, but it keeps it consistant.
I would like a values-like method to return partial objects, and then
requesting any field thats not "fill
Hey, why am I wrong? :(
Instance caching isn't psychic, it just says "this foreign key was
queried for, use the hashtable". Do you want me to say for m in
instances: m.foreign = my_already_queried_value just so I can use it
in templates? If Im referencing this in a view, sure, I'll use the
prebui
So we're not going to support group by at all, even though is
extremely simple? I don't understand why everyone says mine (and
Curse's and many other peoples) use of SQL is so uncommon. I'd
guarantee almost every developer and I know who writes any kind of
scalable code (and I've seen what they've
Sorry -- I missed page 2. So GROUP BY and similar things will be
supported through an Aggregates base class?
On Mar 18, 6:36 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> On Wed, Mar 19, 2008 at 9:26 AM, Justin Fagnani
>
> <[EMAIL PROTECTED]> wrote:
> > Hey Nicolas,
>
> > It seems to be
Ive been having to dig into code vs documentation lately, and there
are *tons* of uses of items() vs iteritems(). I was wondering why this
is?
I did a quick benchmark, on an example I found in newforms, to try and
give myself an answer:
In [31]: timeit.Timer("attrs2=attrs.copy();[(field_name,
at
, you need group by.
Btw, your example doesn't work, having happens after the query
finishes executing, not within the where clause. That specific use
case *has* to execute exaclty as shown.
On Mar 24, 6:12 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> On Mon, Mar 24,
ra(having=['count(1) =
2']).group_by('id').count()
On Mar 24, 6:12 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> On Mon, Mar 24, 2008 at 7:19 AM, David Cramer <[EMAIL PROTECTED]> wrote:
>
> > So we're not going to support gr
SmileyChris pointed me here. I wrote up a rant today about newforms
and what I've done to keep it easy (quick) for building forms.
http://www.davidcramer.net/code/111/making-django-newforms-useful.html
Maybe some of those ideas will be of help. Keep in mind, I use Jinja,
so it's got a lot more ca
I wouldn't say insecure, but its a big gotcha. I've done it a quite a
few times where I forgot the () :)
On Apr 10, 5:53 am, Thomas Guettler <[EMAIL PROTECTED]> wrote:
> Hi,
>
> is_staff, is_active, is_superuser are attributes.
>
> is_anonymous, is_authenticated are methods.
>
> This is insecure
Let's move get_FOO_x off of the models and on to their actual objects:
mymodel.choicefield.display()
mymodel.filedfield.save_file()
etc.
Why?
- Clutters the model namespace
- [Assumption] Performance gain by removing them as it creates extra
lambda functions to attach them.
I'm guessing this
Why wouldn't you just do this in a middleware? A decorator, or a
clean_X on forms would not handle every incoming request like he
wants.
On Apr 10, 11:26 am, Gábor Farkas <[EMAIL PROTECTED]> wrote:
> On Thu, Apr 10, 2008 at 06:44:35AM -0700, simonb wrote:
>
> > On Apr 10, 2:48 pm, Gábor Farkas <[
I'd like to offer a solution to many problems I've had, directing the
error handlers where I want them to go:
- I want to be able to choose what templates they render
- I want them to be able to work with Jinja ;)
I was thinking that something along the lines of this could be done:
404_HANDLER
Alright, it seems this already sort of exists, ignore me ;)
On Apr 11, 11:34 am, David Cramer <[EMAIL PROTECTED]> wrote:
> I'd like to offer a solution to many problems I've had, directing the
> error handlers where I want them to go:
>
> - I want to be able to choos
Can we start setting some milestones so SVN stops being SVN :)
E.g. a .97 release, or .96.2 or something. It would make things a lot
more sane to know where you're at, as everyones using SVN now, but SVN
changes so much from X revision to Y revision that there really needs
to be tagged releases.
it would also be helpful to track 1.0 tickets(those referenced
> on the VersionOneFeatures wiki page. Just my thoughts.
>
> On Apr 18, 11:59 am, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
>
> > On Wed, Apr 16, 2008 at 6:47 PM, David Cramer <[EMAIL PROTECTED]> wrote
+1 because this is annoying behavior.
I ALWAYS run scripts with DEBUG on, that doesn't mean they're on a
production server, because these things are cronned. And I'm always
doing stuff that involves the shell, etc, (imports) where debug is on.
The first thing I've had to do in any shell session,
I'm -1 against any change to this. In most use cases, it's not as
simple as resorting your python results, or refiltering them, as you
have sliced the queryset and the query needs to be executed again to
retrieve proper results.
On Apr 17, 11:18 am, Travis Parker <[EMAIL PROTECTED]> wrote:
> > I'
Now that the branch is merged in I have a few things I'll nitpick
on :)
1) order_by() resets the ordering, but select_related() does not.
Would it not make more sense to keep APIs the same? So something like
order_by(False) and a similar option for select_related?
2) Is the issue still present i
I don't really like the idea of having extra options on save (mostly
because I have a lot of save calls that already. Maybe I don't quite
see the point. I proposed an internal flag a while back which would
determine if something was actually being created or updated. I don't
think it was accepted
Is it my understanding that aggregate would not return an actual
object (from the original examples above).
Also, in regards to HAVING support. Unless you plan to implement logic
into .filter() which says "oh hey this is from an aggregate, using
having" then this is a MUST. There's no other way y
says "HEY WE JUST CHANGED THE ENTIRE DBAPI ALL YOUR HACKS
WILL BREAK" (I didn't even know QSRF was released until someone
pointed it out to me)
On Apr 29, 10:51 am, "James Bennett" <[EMAIL PROTECTED]> wrote:
> On Tue, Apr 29, 2008 at 11:35 AM, David Cramer <[EMA
Yes im aware of the backwards incompatibility page but that mostly covers the
public api. A lot of time for our uses we have to go beyond just using the
public api. This is another situation where having more releases could help :)
-Original Message-
From: Marty Alchin <[EMAIL PROTECTED
n log.
-Original Message-
From: James Bennett <[EMAIL PROTECTED]>
Sent: Tuesday, April 29, 2008 1:46 PM
To: django-developers@googlegroups.com
Subject: Re: QSRF Related
On Tue, Apr 29, 2008 at 3:38 PM, David Cramer <[EMAIL PROTECTED]> wrote:
> Yes im aware of the backwards
y noy
-Original Message-
From: James Bennett <[EMAIL PROTECTED]>
Sent: Tuesday, April 29, 2008 1:57 PM
To: django-developers@googlegroups.com
Subject: Re: QSRF Related
On Tue, Apr 29, 2008 at 3:54 PM, David Cramer <[EMAIL PROTECTED]> wrote:
> If I update from python 2.4 to 2.5 I can
lopers@googlegroups.com
Subject: Re: QSRF Related
David Cramer wrote:
> When an api is limited how would you propose to extend it? You do it the way
> OO is built.
> When releases happen you can expect things to break. When they don't how do
> you expect to
> know when you are s
+1 on pk index fix
as for auth_user, username being indexed would be good, but I believe
the hash is calculated completely outside of SQL, so there's no need
to index password.
On Apr 29, 12:15 pm, Ed Menendez <[EMAIL PROTECTED]> wrote:
> When creating a one to one table or a table with a compou
Gonsalves <[EMAIL PROTECTED]> wrote:
> On 29-Apr-08, at 11:25 PM, David Cramer wrote:
>
> > WILL BREAK" (I didn't even know QSRF was released until someone
> > pointed it out to me)
>
> must have been about a million messages congratulating malcolm on
a few emails, then how do you
> find the time to check a page every day? or even every half day? Also you
> should check these things BEFORE you do a svn update, rather than after.
>
> Regards,
>
> Mike Scott
>
>
> On Wed, Apr 30, 2008 at 2:25 PM, David Cramer <[EMAIL
> that isn't quite readable without double checking the documentation. I
> don't think you could find any argument name that would make that
> functionality clear with a single argument.
>
>
> >
>
--
David Cramer
Director of Technology
iBegin
http://www.ibegin
rote:
> > On Thu, May 1, 2008 at 10:31 AM, David Cramer <[EMAIL PROTECTED]> wrote:
> >
> > > I'm still not quite sure why we need any additional methods, or flags,
> or
> > anything. Can someone explain to me where the underlying API is having
> > is
If annotate is equivilent to group by thenn ordering or seperation shouldn't
matter. In my opinion it should function just like any other filtering and just
merge together. Keep in mind I haven't read about the change to filter with
qs-rf yet.
-Original Message-
From: Nicolas Lara <[EM
Also I believe group by shouldn't happen on every column unless explicit. By
default it should group on primary key.
-Original Message-
From: Yuri Baburov <[EMAIL PROTECTED]>
Sent: Thursday, May 01, 2008 1:53 PM
To: django-developers@googlegroups.com
Subject: Re: Aggregate Support to the
gt; I like the line of thought that lead to this, but find myself in the
> insert/create and update camp. Internally, we've been using some
> monkeypatching to add .insert and .update methods to all models (we
> needed this functionality on models that were in contrib).
>
>
&
Let me also bring up once again, that this is what all the other major DB
layers that I've looked at do. So it doesn't seem like it's a bad solution
at all.
On Sun, May 4, 2008 at 11:11 PM, James Bennett <[EMAIL PROTECTED]>
wrote:
>
> On Mon, May 5, 2008 at 1:
Sphinx has very good documentation, and a full implementation in
Django is available: http://code.google.com/p/django-sphinx/
On May 5, 7:05 am, mrts <[EMAIL PROTECTED]> wrote:
> Excellent. Looking forward for the finished project!
>
> On May 5, 4:50 pm, Ben Firshman <[EMAIL PROTECTED]> wrote:
>
Can someone add it to the BackwardsIncompatibeChanges page?
I saw the warning, and briefly skimmed over the page and switched to
Paginator. To my suprise, there was a little clause at the bottom
saying "USE QUERYSETPAGINATOR" which I didn't notice. You can guess
what I was thinking when I saw it
x27;t use it without
subclassing.
If it's not an iterable though, probably should be :)
On May 5, 6:59 pm, SmileyChris <[EMAIL PROTECTED]> wrote:
> You were using a new feature (albeit the wrong one) so that's not
> really a backwards incompatible issue, is it?
>
> On May 6,
Here is the patch i was talking about:
http://code.djangoproject.com/ticket/5309
On Apr 28, 5:02 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Mon, 2008-04-28 at 13:49 +0200, David Danier wrote:
> > > For this particular case it saves a whole line. One concern I have is
> > > that if th
I'd like to present my concept for partial models, which would be an
attempt to replace the use of .values() returning a dictionary
(although .values() still has uses if you dont actually want an
instance). Keep in mind, the way I'm presenting this would keep #17
working :)
values, values_tuple,
Sort of, although I'm going to go against Adrian on the hide() method (I'd
rather be explicit than implicit).
On Tue, May 6, 2008 at 8:46 PM, Russell Keith-Magee <[EMAIL PROTECTED]>
wrote:
>
> On Wed, May 7, 2008 at 11:35 AM, David Cramer <[EMAIL PROTECTED]> wrote:
I swear I saw something about work being done on this. Has anyone
begun? If not I'll gladly throw up a patch to get it into trunk.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to
What is the difference between annotate and aggregate? They seem like
they'd do the same thing, except annotate sounds like it should be
doing GROUP BY, which, if that's the case, then this goes against the
very reasoning which a group_by or something similar should not be
used. The logic in the i
gregate on a foreign table).
>
> On 12 mei, 16:50, David Cramer <[EMAIL PROTECTED]> wrote:
>
> > What is the difference between annotate and aggregate? They seem like
> > they'd do the same thing, except annotate sounds like it should be
> > doing GROUP BY
I realize how the aggregates work, but if annotate is just for
aggregates, then remove it as a standalone method. If it's not, then
it should solve all the problems with one blow.
On May 12, 4:37 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> On Mon, May 12,
That's much more clear than what I had been reading.
If that is the case, then annotate would replace GROUP BY, and should
also be able to replace distinct().
On May 12, 9:27 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> On Tue, May 13, 2008 at 12:01 PM, David
The database engine usually can't fill that in anyways, you should
probably quote it yourself (correct me if I'm wrong).
On May 13, 9:15 am, Dave Lowe <[EMAIL PROTECTED]> wrote:
> Ever since the querset-refactor merge, params in the 'tables' argument
> don't seem to be filled. The documentation d
DISTINCT and GROUP BY are both annotating the results. Taking many rows, and
turning them into a single row based on a key. DISTINCT would be the same as
GROUP BY every, field, in, the, select.
On Tue, May 13, 2008 at 10:29 AM, Collin Grady <[EMAIL PROTECTED]> wrote:
>
> David Cra
Im not suggestung to replace the sql use just that they are identical in
abstraction, and if the api truly doesn't want an sql feel, then it shouldn't
have one
-Original Message-
From: Sander Steffann <[EMAIL PROTECTED]>
Sent: Tuesday, May 13, 2008 1:03 PM
To: django-developers@googlegr
On Fri, May 23, 2008 at 1:29 PM, Gary Wilson Jr. <[EMAIL PROTECTED]>
wrote:
>
> David Cramer wrote:
> > I'd like to present my concept for partial models, which would be an
> > attempt to replace the use of .values() returning a dictionary
> > (although .va
08 at 3:18 PM, Gary Wilson Jr. <[EMAIL PROTECTED]>
wrote:
>
> David Cramer wrote:
> > IMO show() and hide() are extremely ugly. And I think .values() is
> becoming
> > ugly with the addition of values_tuple or whatever it's called. I don't
> see
> > a
gt; attributes from related objects is going to be more painful, though...
> dict easily wins there.
>
> But when I tried using the model __new__ and then setting attributes,
> it took 2.04 us; I can't figure out why it's that much slower.
>
> As for signals, maybe we d
201 - 279 of 279 matches
Mail list logo
