That's actually not quite caching. That's just optimizing memory
usage.
Here's my proposal:
* Create a custom ModelBase, CachedModelBase -- this would rely on
CACHE_BACKEND to pull get() requests (PK requests) using a similar
method as #17s optimization
* CachedModelBase overrides save/delete to
p for the task though :)
On Sep 15, 10:42 pm, David Cramer <[EMAIL PROTECTED]> wrote:
> That's actually not quite caching. That's just optimizing memory
> usage.
>
> Here's my proposal:
>
> * Create a custom ModelBase, CachedModelBase -- this would rely on
&
I +1 on truncate, I'd suggest submitting a ticket
On Sep 19, 5:17 am, "Wensing, Matthew \(CNI-Palm Beach\)"
<[EMAIL PROTECTED]> wrote:
> Maybe there should be a .truncate()? Heh.
>
> Matt
>
> -Original Message-
> From: django-developers@googlegroups.com
>
> [mailto:[EMAIL PROTECTED] On B
Yes, my biggest argument is I want to use .get_or_create() and I don't
have an instance of the row (the id) I'm trying to insert. I'm *not*
going to query for this instance (I'll write SQL before I add extra
queries just to do an update/insert), and I don't like creating a fake
temporary object, w
I don't believe .create() allows you to say myforeignkey=1, correct me
if I'm wrong, but I think it throws an error about it needing to be a
instance.
On Sep 19, 11:30 am, "James Bennett" <[EMAIL PROTECTED]> wrote:
> On 9/19/07, David Cramer <[EMAIL PROTECTE
The only way this can be done as of current is by saying
"MYmodel(id=1)" which is a hack. This technically shouldn't be done as
you're instantiating an object without a dataset. What happens when
the shared memory select related patch were to go in? You'd now have
an instance of a model thats comp
Hi,
Would anyone else find this useful?
I'm quite happy to take a shot at it, if anyone else will find it of
any use.
Thanks,
David
--
David Reynolds
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
You received this message because you are subscribed t
On 26 Sep 2007, at 4:07 pm, David Reynolds wrote:
>
> Hi,
>
> Would anyone else find this useful?
>
> I'm quite happy to take a shot at it, if anyone else will find it of
> any use.
Just to clarify:
http://code.djangoproject.com/ticket/5610
Anyone any thoughts?
.py dumpdata product.Category
or is there a better way, in case you want to do more than one model
from an app?
Thanks,
Dave
--
David Reynolds
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"
n, this would keep everything consistent with the test command.
Ok, I'll have a bash at it tonight.
Thanks Russell.
--
David Reynolds
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django d
Any chance of a status update?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send
then altering the call to
> _load_post_and_files so that it only populates POST or PUT when the
> method is appropriate.
>
Hi malcolm,
I use django-rest-interface too and I have this bug which need to be
quickly fixed so I submitted a patch which need review on #5682, let
me know
, even if
I admit that a backward incompatible change could be a pain. The
option (3) seems more natural to me to make the difference between
what you post and the POST verb, it's more explicit. What about
self.PUT in this scenario?
>
> So then the only change that is needed is to also pop
2007/10/7, Malcolm Tredinnick <[EMAIL PROTECTED]>:
>
> On Sun, 2007-10-07 at 02:39 +0200, David Larlet wrote:
> > The
> > option (3) seems more natural to me to make the difference between
> > what you post and the POST verb, it's more explicit. What
uld talk to Andreas about posting some of the discussions we had
> and where we left of on the wiki and creating a project mailing list so
> that other people can get in on the fun here.
Great idea, I'll be glad to help you (if I can).
Regards,
David
--~--~-~--~~-
2007/10/8, Peter Nixon <[EMAIL PROTECTED]>:
>
> Hi David
>
> Thanks for doing this. I have written a patch for mod_python and added it to
> the ticket. I have tested it and deployed it with a patched rest api in
> production ;-)
>
Ok, can you add your patch against
Hi,
I've just added this ticket (#5737), which I am quite keen to fix, as
it would be useful for the project I'm currently working on, can
anyone give me any advice as to whether this is something that can be
fixed and where I should look to fix it?
Thanks,
D
2007/10/10, David Larlet <[EMAIL PROTECTED]>:
>
> BTW, no more thought about the way of handling PUT? I've just added a
> patch against test.client which add .put() and .delete(), I'm waiting
> for (a) reaction(s) to add tests and documentation.
>
Sorry for insi
2007/10/18, Malcolm Tredinnick <[EMAIL PROTECTED]>:
>
> On Tue, 2007-10-16 at 21:52 +0200, David Larlet wrote:
> > 2007/10/10, David Larlet <[EMAIL PROTECTED]>:
> > >
> > > BTW, no more thought about the way of handling PUT? I've just added a
>
I thought that it was more appropriated to post it on the devlist
because it sounds like a bug but ok let's move it on the userlist, sorry
for the noise here. I'll be glad to hear your solution.
David
Marty Alchin a écrit :
> This should probably be asked on django-users, as it
y is that base_fields
contains the initial data before this line but my returned form not.
Did somebody use this argument and can confirm?
Regards,
David
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"
Marty Alchin a écrit :
>>> On 11/7/07, David Larlet <[EMAIL PROTECTED]> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I'd spent a long time finding that bug but I want to be sure before
>>>> submittin
me as we did
> last time:
Hurrah! Sprinting in the holiday season! ;)
--
David Reynolds
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, se
Marty Alchin a écrit :
> On 11/7/07, David Larlet <[EMAIL PROTECTED]> wrote:
>
>> Unfortunately, what happens with my Form is exactly what I'd like to do:
>> create a generic form from a Form class which define fields (with
>> widgets, etc) and methods and wh
Any chance of adding signals to ManyToMany fields?
example usage:
- I have a perm_cache -- that I'm pretty sure django.contrib.auth also
has.
- I have instance caching, or memcache that perm cache (or in our
case, both).
- I update that perm_cache, in the admin, and need to reset the perm
cache(s
t any tickets
relating to it, add one, claim it and set to work :)
0 - http://code.djangoproject.com/query
--
David Reynolds
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django develope
I was debugging a query earlier and noticed that ManyToMany filter
calls perform a left outer join.
The only use case of this I could come up with is
myfield__isnull=True. Are there any other reasons this is needed?
If not I'd like to propose changing this to use INNER JOIN (on the
exception of
we use it with GROUP BY statements either way.
On Nov 28, 11:50 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Wed, 2007-11-28 at 11:00 -0800, David Cramer wrote:
> > I was debugging a query earlier and noticed that ManyToMany filter
> > calls perform a left outer join
Is this set for 2009? ;)
About subclassing, what was agreed upon? I'm going to rip my hair out
if it does OneToOne relations and strange db queries :P
I think the major features listed here are good -- qsrf is the biggest
one I want in.. come on .98? :)
On Nov 30, 9:49 am, "Bryan L. Fordham" <[
ll around the world, I would find it incredibly satisfying, in
> a devilish way, to release this thing and slap a "2.0" on it. It would
> underscore the project's stability while at the same time
> demonstrating that version numbers are completely arbitrary.
Worth it just fo
hat am I forgetting?
Maybe use request.DATA instead of POST as discussed in #5682? It's
backward compatible and not a Big Stuff but can require a lot of
changes if it becomes the right way to do®.
David
--~--~-~--~~~---~--~~
You received this message because yo
ld be
differentiated between POST and GET as you don't want someone to start
sending data to your forms through request.GET.
On 18 oct, 04:32, "David Larlet" <[EMAIL PROTECTED]> wrote:
> 2007/10/18, Malcolm Tredinnick <[EMAIL PROTECTED]>:
>
>
>
>
>
> &g
I just want to bring this up again, because Model Inheritance is a
HUGE thing...
I have not seen any final discussion on how it's going to work (http://
code.djangoproject.com/wiki/ModelInheritance). Last I heard it was
still up in the air. If there are features that are unsure of, I don't
see ho
I would also recommend a different name -- maybe django-gcalender,
since its specific to the calender app. After all, Google is quite
big :)
On Dec 3, 9:03 am, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> On 12/3/07, Patryk Zawadzki <[EMAIL PROTECTED]> wrote:
>
> > I know django-users might b
I'm also -1 on the strange names -- especially something like "Paris
1945" :P
On Dec 3, 11:51 am, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> On Dec 3, 2007 9:52 AM, Panos <[EMAIL PROTECTED]> wrote:
>
> > Having major releases include a nickname might be nice too (like
> > Ubuntu & OS X).
>
>
For the most part I'm just doing if request.POST to validate.
On Dec 3, 11:16 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Mon, 2007-12-03 at 11:00 -0800, David Cramer wrote:
> > Just my 2 cents...
>
> > If you drop request.POST, request.GET, and replace t
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
On 10 Dec 2007, at 5:35 am, Eratothene wrote:
> Don't bother I have just figured out why.
Can you say why, just for completeness of the archives?
Thanks,
David
--
David Reynolds
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
You received this message bec
> > 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
ailable (which might not be the case when not
using django.contrib.auth or not using an auth-system at all) and that
it has a is_authenticated/message_set attribute (which might be ok, as
this could be called "API" you need to reproduce).
Greetings, David Danier
--~--~-~--~~-
said before: It only fixes one
application out of many.
Instead replacing code like LogEntry.objects.log_action(...) with
request.user.logentry_set.create(...) would help, not only in the admin.
Greetings, David Danier
--~--~-~--~~~---~--~~
You received t
to replace
django.contrib.auth gives some nice advantages, even over the current
backends-system.
For example you do not need to sync your db with LDAP when using LDAP as
the backend. A User-model only containing the DN would be enough here.
Greetings, David Danier
--~--~-~--~~--
to add the admin-app only to have a
nice and clean permission-framework?). It looks to me like the
"unreplaceable django.contrib.auth"-problem will be fixed (or worked
around) only in the admin now, without considering adding this
functionality to the entire django-framework.
Greetings, D
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 D
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
in November:
http://groups.google.com/group/django-users/browse_thread/thread/
7fd54d4fa0c1d97f/799ef2412b81ff79
But nothing was ever done..
--
David Reynolds
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
one:" test. If you replace
force_unicode by to_unicode it works. I'd submitted a bug and a patch
on Trac, see #6303.
While we are at feeds, I got a "cosmetic" question. It seems that each
generated feed in Django is not highlighted by Firefox when you read
the source. Is
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
Hi,
Are emails from trac still working? As I've had a ticket closed and
another commented upon and not received email from these. Is
something not working?
Thanks,
David
--
David Reynolds
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
You received this me
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
as a new backward
incompatible change?
Best,
David
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To u
Le 5 févr. 08 à 22:05, Malcolm Tredinnick a écrit :
>
>
> On Tue, 2008-02-05 at 16:14 +0100, David Larlet wrote:
>> Hello,
>>
>> I'd just updated my local version of django and it raises errors due
>> to 7084 changeset (extends should be the first tag). I p
Thanks, I try to do my best and five mistakes in the same sentence is
not that bad ;)
Cheers,
David
Le 7 févr. 08 à 15:31, J. Cliff Dyer a écrit :
>
> I made a couple of minor grammatical changes for clarity, but your
> english was pretty good, David.
>
> Cheers,
> Cliff
&
previously in a broken site if the extended
> template was being used in more than one depth of inheritance.
>
>>
>> Still, it's a wiki, feel free to update it if you like.
>
> Yea, go ahead and update it David, I think it's fair enough.
>
I'd tried to
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
nt.
>
>
>> Anyways, we will study your code and if you agree, we can contribute
>> in a branch leaded by you.
>
> I look forward to hearing your thoughts!
I'm with you too, happy to see that this project is still alive.
Cheers,
David
--~--~-~--~~~
out once already, but
> again for sake of sanity...
>
> The list of people I am disagreeing with in this thread:
>
> * David
>
> The list of people I am not disagreeing with in this thread:
>
> * Everyone except David
>
> Can we move past that?
>
> --
> "B
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
class User(models.RDFModel):
user = whatever(DjangoUser.name)
# mmh, I need more time to think about the way to declare triples
class Meta:
source = sources.FOAFSource()
Good luck!
Cheers,
David
--~--~-~--~~~---~--~~
You received this message beca
w+)/',
'pk_value': '(?P\d+)/',
'foo_args': '(?P\d+)?/?',
etc
}
urlpatterns = pattern('',
url(r'%(username)s%(pk_value)s%(foo_args)s' % re_urls, myfunction)
)
Isn't it more readable? And it do not break an
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'
ems with naming the new parameter
and difficulties in creating self-explaining possible values ("not
must_create", rather than "must_not_create").
Just my 2 cents, David Danier
--~--~-~--~~~---~--~~
You received this message because you are subsc
Le 28 avr. 08 à 09:33, David Danier a écrit :
>
>> Sometimes when calling save(), we know (for business reasons) that it
>> must create a new object or raise an error. Similarly, in other
>> cases,
>> it either must update an existing object or raise an error.
&
ethods. Every save() call. Currently and with the parameter approach,
> *zero* existing code has to change initially. If you want to support the
> must insert vs. must update difference, you can add a parameter (or two,
> depending on which approach we take) and it's still backwards
&
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
601 - 700 of 807 matches
Mail list logo
