One of the last of my feature-needs (for optimization reasons) is the
ability to specify what fields can, or can't be ordered in the admin
apps.
I'd like to propose something along the lines of:
order_by_fields = ('field', 'field', 'field')
This would allow you to only order by fields which
I'm not sure on AggreateField either. What if you just do like
("Photo", "user__exact=self.user") or something. Currently there's no
rerepsentation for "self" in Django QuerySet's, so this is a hard
thing to call. Also, we need a way to support callables.
e.g. models.MirrorField("my_callable_or_a
Before this gets accepted, I'd like to throw in the proposal of
storing this in the session vs a huge URL. That and a hash seem to be
the common approach to storing search paths.
On Nov 11, 7:19 am, Jonas Pfeil <[EMAIL PROTECTED]> wrote:
> Currently if you search in the admin, use some kind of fi
the URL. Naturally if
> you do it this way, you'd also want to have a visible "clear filters"
> link so that there's some way to reset that state, I didn't check the
> patch to see if this was already included.
>
> On Nov 11, 2008, at 4:35 PM, David Cr
e a
boolean, or a list. This, in my eyes, is fully backwards compatible, as its
only an addition to the public API, and a bug fix.
On Tue, Nov 11, 2008 at 3:17 AM, Malcolm Tredinnick <
[EMAIL PROTECTED]> wrote:
>
>
> On Mon, 2008-11-10 at 17:13 -0800, David Cramer wrote:
>
hat functionality,
> I would ask for something to be added to the admin that would print
> out a URL that you could give to another user to get the filtering you
> were just using. Which sounds handy, but is a separate ticket from
> what we're discussing here.
>
> On
;d really want to save all three,
> because they all go together insofar as returning you to *exactly* the
> view you were last using. If you're going to preserve it at all,
> might as well do it right and preserve it as pristinely as possible.
>
> On Nov 11, 2008, at 5:3
Ya this is much more needed for me on ForeignKey's, but that's like
adding magical models (which I like!).
You'd have to add left order, and right order fields, on the model
referenced in the ForeignKey, to have an OrderedForeignKey field.
This, without migrations, would not be fun with DB mainte
Here's my proposal for the composite keys (which act much like generic
keys except more useful):
class MyModel2:
pass
class MyModel3:
pk_part1 = models.AutoField()
pk_part2 = models.ForeignKey(MyModel2)
name = models.TextField()
class MyModel:
pk_part1 = models.IntegerField(
, this issue is all thats stopping me from completing the
composite PKs patch.
On Nov 13, 7:19 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Thu, 2008-11-13 at 10:53 -0800, David Cramer wrote:
> > Here's my proposal for the composite keys (which act much like
I volunteer for #17!
And I have working code for a pretty simplistic message handler which
is session vs database based (which is one of the proposals, sort of).
So I guess if that's whats wanted, I can mold it to fit what has been
discussed.
On Nov 13, 5:03 pm, "Jacob Kaplan-Moss" <[EMAIL PROTE
MAIL PROTECTED]>
wrote:
> On Thu, 2008-11-13 at 19:50 -0800, David Cramer wrote:
> > I was thinking beyond just handling Foreign Keys actually when I wrote
> > this up. It would allow for a more generic version of a generic
> > foreign key.
>
> Generic relations are quite
Not the *best* place to post this, but it does relate to Django dev.
Is it possible, and if so how, could one branch the Django trunk, and
throw it on Github?
>From what I've read I could then do some kind of "svn up" to merge in
latest changes easily from trunk, and also work on my branch (e.g.
I personally was a 0 on this one. Let me explain why. I want Django to
be a strong platform for developers, like myself, who really want the
opportunity to have power in the framework, as well as features. As of
lately I have been using Rails for a project, and to be quite honest,
the maturity and
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
> options available ranging from asking around for help to organizing a
> team to contracting someone qualified.
>
> Finally, please keep in mind that the feature list we're drafting
> right now isn't set it stone. Anything that gets finished between now
> and the feature
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&#
here is one unrelated change I accidently
committed. The list_select_related changes I proposed.
There is also an issue with URL resolving in the admin (its a 1.1
proposal) so it's using a , vs a / for the delimiter, but it's a
simply setting change.
On Nov 16, 5:50 pm, David Cramer <[E
the branch as
well.
On Sun, Nov 16, 2008 at 6:00 PM, Jacob Kaplan-Moss <
[EMAIL PROTECTED]> wrote:
>
> 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 loo
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
I've been trying to dump some data to fixtures for the last couple
days, and I've ran into various problems each time. It's been quite
difficult each time to determine the problems, as there's no useful
tracebacks on the error messages:
[EMAIL PROTECTED]:~/Development/iplatform] ./manage.py dumpd
Ahh. I suppose that makes sense. Is there any reason it doesn't show
them by default?
On Nov 17, 3:45 pm, "Alex Koshelev" <[EMAIL PROTECTED]> wrote:
> Try to use `--traceback` switch that prints exception's traceback
>
> On Tue, Nov 18, 2008 at 00:41, Dav
My only opinion, is beyond the tutorial, people would much rather
search then dig for the link :)
On Nov 18, 10:54 am, "Clint Ecker" <[EMAIL PROTECTED]> wrote:
> Aw, I had actually started to like/get used to the old-new way ;)
>
>
>
> On Tue, Nov 18, 2008 at 1:44 AM, Adrian Holovaty <[EMAIL PROT
It would be a lot more useful if you put details in to it. Right now
this post looks like spam on the developers group.
I'm curious as to your issues with the Paginator class. Works great
for me (barring some additional context vars).
On Nov 17, 11:43 pm, Dipankar Sarkar <[EMAIL PROTECTED]> wrot
specific rows, since that seems to use the primary key. So I clear()
>> and re-add instead of delete()-ing, since that doesn't use the primary
>> key. Fragile, but it beats doing the puppy-eyes to the DBA.
>>
>
>
> >
>
--
David Cramer
Director of Technology
iB
To avoid messing with the 1.1 Roadmap anymore. What happened with defer
(). I know personally myself, and several others who expressed
opinions, wanted more than just an exclude option, but an include-only
option.
Is this part of the "Exclude fields in a SELECT (QuerySet.defer())" or
is this just
elly" <[EMAIL PROTECTED]> wrote:
>
> > On Fri, Nov 21, 2008 at 1:05 PM, David Cramer <[EMAIL PROTECTED]> wrote:
> > > I won't use defer, and I won't recommend people use it. I think it's
> > > not good practice. It's like using .sele
Ok with all of that being said. I've checked the ticket (once again),
and there doesn't seem to be any API proposed for fields as include-
only. Is there another ticket other than #5420?
On Nov 21, 7:15 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Fri, 2008-11-21 at
2, 4:13 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> On Sat, Nov 22, 2008 at 3:50 PM, David Cramer <[EMAIL PROTECTED]> wrote:
> > Ok with all of that being said. I've checked the ticket (once again),
> > and there doesn't seem to be any API p
+1
Update your damn distros. Generators are important :)
On Nov 26, 10:33 am, "Gary Wilson Jr." <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 26, 2008 at 7:23 AM, varikin <[EMAIL PROTECTED]> wrote:
> > On Nov 25, 7:16 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
> > wrote:
> >> However, even saying Dja
I have nothing against removing it from the built-in libs, but as long
as we look for the system's libraries first what's the big downside to
keeping it?
On Dec 1, 5:02 am, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> On Mon, Dec 1, 2008 at 4:21 PM, James Bennett <[EMAIL PROTECTED]> wrote:
I'll agree 100% that a request.is_ajax() hook to output some
simplified data would be awesome.
On Dec 2, 10:42 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
wrote:
> Perhaps a better solution would be to vary based on request.is_ajax().
>
> Alex
>
> On Dec 2, 11:37 pm, kernel1983 <[EMAIL PROTECTED]
So I needed the ability to specify initial data for a wizard, and I
also liked the idea of storing it in the session (vs the POST). I was
pointed to the SessionWizard patch, and I believe this was a 1.1
possibility as well, so I figured I'd bring up the numerous issues.
First and foremost, the la
t have
to call methods manual. Let's decide which is more common.
On Dec 3, 7:50 pm, David Cramer <[EMAIL PROTECTED]> wrote:
> So I needed the ability to specify initial data for a wizard, and I
> also liked the idea of storing it in the session (vs the POST). I was
> pointed t
Awesome to see some people working on this. I had tried pre-queryset
refactor and It was just not doable witht he fields API. Can't wait to
see the final result of this :)
I'm also agreeing with the API of field = BitMaskField(choices=LIST)
On Dec 6, 10:37 am, Carl Meyer <[EMAIL PROTECTED]> wrot
of forms based on the data
stored each time, but not really sure.
On Dec 4, 5:23 am, "Hanne Moa" <[EMAIL PROTECTED]> wrote:
> On Thu, Dec 4, 2008 at 03:34, David Cramer <[EMAIL PROTECTED]> wrote:
> > When the done() method is called, the session is also cleared unles
nt and all new choices should be added to the end. Another option
> is to store the choices in something like the django_content_type field and
> verify on syncdb (or some other place, not sure where it would go) that any
> old field types were not assigned to a new mask.
>
> Craig
Oh no, now I'm going to get more emails saying the code needs
updated :)
There is a concept in the orm cache that splits it though, so you can
probably use that idea.
On Dec 7, 10:04 am, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote:
> On Sun, Dec 7, 2008 at 8:55 AM, Calvin Spealman <[EMAIL PROTECTED
To be perfectly honest, I'm +1 on a solution. I didn't realize this
was happening either.
Time to monkey-patch QuerySet's delete() method :)
(I'm also a bit curious as to how its handling cascades in MySQL when
it's not looping through each object)
On Dec 10, 12:43 pm, "Karen Tracey" <[EMAIL PR
I'd like to propose the addition of some useful (and common) fields in
the django core. Things like a JSONFied, YAMLField, HTMLField?,
UUIDField, etc.
A lot of these seem like common things people use, and while many
examples are out there, it'd be nice to simply include these in core
so there's
gt; dealt with. (And I think if they subclass TextField they are reasonably easy
> to do without too much backend awareness.)
>
> My $0.02,
> Mike
>
> On Mon, Dec 15, 2008 at 5:07 PM, David Cramer wrote:
>
> > I'd like to propose the addition of some useful (
Recently we've been doing a lot of work with custom fields, and have
had a few inconveniences come up. Some minor, some not so much. I'd
like to propose a few changes to the API to make it easier to write
custom fields, especially those which use custom data structures.
The first of which, is the
I should also note, that these changes, could possibly be carried over into
Model Field's. As IIRC they were suffering from some of the same problems.
On Tue, Dec 16, 2008 at 12:03 PM, Jacob Kaplan-Moss <
jacob.kaplanm...@gmail.com> wrote:
>
> On Tue, Dec 16, 2008 at 9:06 AM, Da
Could we just use a lazy proxy for the value value? When it's executed, it
could then just call the get_value_from_db method (or whatever).
On Tue, Dec 16, 2008 at 12:37 PM, Marty Alchin wrote:
>
> On Tue, Dec 16, 2008 at 1:03 PM, Jacob Kaplan-Moss
> wrote:
> > This seems like a good idea to m
We simply send them to localhost. Learned the lesson long ago to not
spam a normal email account with it :)
On Dec 16, 4:15 pm, "Jeremy Dunck" wrote:
> On Tue, Dec 16, 2008 at 3:44 PM, Jacob Kaplan-Moss
>
>
>
> wrote:
>
> > On Tue, Dec 16, 2008 at 11:56 AM, Jeremy Dunck wrote:
> >> Since sendi
It would be kind of neat to have some generic autodiscover
functionality for this kind of stuff. Not only could you reuse it in
things like sitemaps, templatetags, and admin, but it could be used by
other developers for plugable systems of their own.
On Dec 19, 4:01 am, andybak wrote:
> I have r
While the Sitemaps framework in Django is fairly complete, there's a
few things it's lacking, namely the ability to specify attributes for
a Sitemap index file. We ended up rewriting our sitemaps, but I wanted
to throw our code up here for an example of what we came up. Keep in
mind that we are wr
Actually before I get a "wtf" response, I should note that the two
generators do not quite match. One is rendering a template, the other
is simply yielding XML. The latter approach is what I prefer, but I
was rushing to finish the index generator :)
On Jan 14, 11:49 am, David Cra
I was never a fan of the profile model as it stands. It's not very
practical in every situation I've ever been in. Being that 1.0 was
supposed to be backwards compatible, and this is a public API I think
it needs to stay.
I'd love to see a way to swap out the User model in the future though,
rath
So I had a cool little idea -- to build a CacheManager, which let our
team collaborate with caching controls and not duplicating data in the
cache.
So, here's a rough draft that i hammered out in 15 minutes.
http://www.davidcramer.net/code/50/django-cachemanager.html
Criticism welcomed!
--~--
clean but it's the only other
way I can think of.
On Jul 4, 11:25 pm, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote:
> On 7/5/07, David Cramer <[EMAIL PROTECTED]> wrote:
>
> >http://www.davidcramer.net/code/50/django-cachemanager.html
>
> > Criticism
Sorry, new link: http://dpaste.com/hold/13668/
On Jul 5, 11:41 am, "Honza Král" <[EMAIL PROTECTED]> wrote:
> On 7/5/07, David Cramer <[EMAIL PROTECTED]> wrote:
>
>
>
> > Ya cache invalidation is something you'll always have a problem with.
> &
Here's about as final as we're going to get it for now:
http://dpaste.com/hold/13884/
On Jul 5, 4:07 pm, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote:
> On 7/5/07, Honza Král <[EMAIL PROTECTED]> wrote:
>
> > We haven't tested it for performance (we are building a high-volume
> > site) yet and we sti
Not sure if you guys have seen this, but maybe Django can take a bit
from what it does well.
https://storm.canonical.com/Tutorial
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post t
That's an interesting solution. My main reason for not doing that is
because I've been told the dispatcher sucks (it's slow) and we're
going for speed.
I don't see the reasoning for adding QUERY_ to the cache_key. By
default the cache_key is your db_table. So if your model is
myapp.HelloWorld it
; It just seems that Django's ORM is already syntactically nicer and, other
> than inheritance, Storm doesn't seem to have any really compelling feature.
>
> On 7/10/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
> > On Jul 10, 4:43 pm, David C
Is there any reason why its storing the keys in QueryDict (possibly
others) as unicode?
This seems like a bug, possibly overlooked, but having unicode keys
prevents certain functionality like **request.GET in a method call.
--~--~-~--~~~---~--~~
You received this
Ya it's probably not a great practice. I argued about these should be
str's for an hour yesterday and I was convinced to drop it :)
Gábor Farkas wrote:
> David Cramer wrote:
> > Is there any reason why its storing the keys in QueryDict (possibly
> > others) as unicode?
Is there a specific reason that myfield=None doesn't translate to
myfield__isnull=True in the database backend?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send
It's not so much related to ManyToMany. But None is Python's equiv to
SQL's NULL.
I'd very much like to see it evaluate to such, and I agree,
isnull=True should be deprecated.
On Jul 16, 9:46 am, "Benjamin Slavin" <[EMAIL PROTECTED]>
wrote:
> On 7/16/07,
I forsee a patch incoming.. as soon as we make our crazy Django branch
fit w/ trunk :)
Didn't know about __ne before today. A lot easier than throwing on
excludes :)
On Jul 16, 2:19 pm, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> On 7/16/07, David Cramer <[EMAIL
I'm still not quite sure what the point of having None not mean NULL
is. '' is not None, False is not None. If this is what it's currently
doing then the ORM handles it incorrectly. Yes, it may be a backwards
incompatible change, but who relies on None? I've yet to see
myfield=None pull any result
I feel that returning an empty queryset where value=None is just
laziness. Yes, maybe it will break things, but maybe those things are
meant to be broken. You could just as easily say myfield__exact which
would work as it would before, and leave the default to isnull for
None. This is similar to h
I committed a quick patch earlier to trunk that adds group_by()
support.
I can't run the tests on trunk, as we're not quite up that far, but it
should be working.
http://code.djangoproject.com/ticket/4997#comment:1
I plan to add having=[] support to extra as well this weekend.
--~--~-
#x27;choices': 'my_column'}
On Jul 27, 7:49 pm, David Cramer <[EMAIL PROTECTED]> wrote:
> I committed a quick patch earlier to trunk that adds group_by()
> support.
>
> I can't run the tests on trunk, as we're not quite up that far, but it
> should be
n to not put in working fixes right now.
On Jul 27, 8:06 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> On 7/28/07, David Cramer <[EMAIL PROTECTED]> wrote:
>
>
>
> > I committed a quick patch earlier to trunk that adds group_by()
> > support.
&
It's not abusive, and we use Django daily. I looked at the QuerySet
recactoring and I honestly don't like the aggregate() stuff.
We are real people, and developers also :)
On Jul 27, 8:59 pm, "Tom Tobin" <[EMAIL PROTECTED]> wrote:
> On 7/27/07, David Cra
I have taken a bit of time to rewrite part of the QuerySet code
(including select_related). Please, no lectures about a QuerySet
refactoring.
The changes force .filter() to take advantage of select_related.
Before: .filter(mykey__name='Hello') would give you results, but if
you didn't do .select
In my opinion BlobField's need some kind of support inside of Django
before the coming of 0.97 release.
They have never been officially supported, but they were at least
usable (as say a TextField) before Unicode. Now they're unusable as
you run into encoding/decoding issues.
--~--~-~--
I've submitted a ticket and attached part of the patch (the fields
selection on select_related): http://code.djangoproject.com/ticket/5020
On Jul 30, 12:39 pm, David Cramer <[EMAIL PROTECTED]> wrote:
> I have taken a bit of time to rewrite part of the QuerySet code
> (includi
Seems I slipped in the diff. I have to actually apply the patch to at
least 2 different versions of Django with our current setup, can get
tedious :P
*args should be *fields :)
On Aug 1, 9:26 am, Michael Radziej <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 01, David Cramer wrote:
&
t; On Thu, Aug 02, David Cramer wrote:
>
> > Seems I slipped in the diff. I have to actually apply the patch to at
> > least 2 different versions of Django with our current setup, can get
> > tedious :P
>
> > *args should be *fields :)
>
> ;-)
>
> Well, for t
This is round #8 for ideas on how to improve caching mechanisms :)
The way the code works is that it caches all requests to this
ForeignKey in a single dictionary. It then does a lookup on the
primary key (doesn't support multiple pks) and returns it.
This works great when you would need to join
So we all know Django doesn't support multiple pks, big problem, yes.
While looking into a temporary solution to fix some issues I have with
these, I cam across another issue.
Django's check for "is this row in the database", is simply checking
if it has a primary key attribute set. If it does, i
applicable, but that goes into the queryset refactoring.
On Aug 30, 5:13 pm, Collin Grady <[EMAIL PROTECTED]> wrote:
> Russell Keith-Magee said the following:
>
> > On 8/31/07, David Cramer <[EMAIL PROTECTED]> wrote:
> >> Not only would this fix my multiple pk issue
Here's the patch: http://code.djangoproject.com/ticket/5309
On Aug 30, 5:39 pm, David Cramer <[EMAIL PROTECTED]> wrote:
> We were talking it over in IRC, and here's a pretty good solution:
>
> Intially is_stored is set to None. When you do a .get or .create it
> wou
If there are any, then I would expect it'd handle them just as it does
without the flag. The problem is (at least in my eyes) that Django
should not be guessing, and especially should not be doing an extra
query, when you are explicitly saing update or create on an object.
On Aug 31, 2:24 am, "Vs
You promise we have refactoring done by the 14th? ;)
I can see if anyone at the office is interested in participating.
On Sep 5, 1:32 pm, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> It's about time we scheduled an official Django sprint. We've got a
> bunch of features that are almost done bu
If they can host it at the HQ in Mountain View even better, count me
in either way.
On Sep 5, 2:39 pm, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> On 9/5/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> > It's about time we scheduled an official Django sprint.
>
> I've contacted Brian Fitzpa
Only 3 of us from SF? Come on now!
It's for sure that it'll be good at Google's campus?
On Sep 7, 9:20 am, Fernando Gutierrez <[EMAIL PROTECTED]>
wrote:
> On Wed, 2007-09-05 at 15:32 -0500, Adrian Holovaty wrote:
> > It's about time we scheduled an official Django sprint. We've got a
> > bunch o
I've taken the time to upload both our SphinxSearch layer, and our
MediaWiki markup util to Google code today. For more info see my blog
post:
http://www.davidcramer.net/code/54/mediawiki-markup-and-sphinxsearch-for-django.html
I haven't used Google code before, so if theres any problems just le
Thinking about this more, it made more sense in django-users, sorry :)
On Sep 7, 3:30 pm, David Cramer <[EMAIL PROTECTED]> wrote:
> I've taken the time to upload both our SphinxSearch layer, and our
> MediaWiki markup util to Google code today. For more info see my
So in the past months, we've tried several different methods of
handling caching over at Curse. Curse.com for the unfamiliar, we're a
very high traffic dynamic content driven website.
- Caching frequently used querysets with cache.get()/set()
- Caching entire views
- Caching middleware
Now we've
cy information is created and when the cache
> gets invalidated, it is taken into account.
>
> We are still in early stages with this, but the foundation seems
> solid. We still have a fine-grained control over what gets cached and
> what not (caching the entire page simply isn
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
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
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
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" <[
Just my 2 cents...
If you drop request.POST, request.GET, and replace them all with
request.DATA -- we're going to again be branching away from Django
trunk.
For our uses -- POST and GET are completely different things --
whether you use one at a time or not is unrelated. Things should be
differ
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
101 - 200 of 279 matches
Mail list logo
