On 12/29/05, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> BTW,
> the query syntax is changing quite a bit -- see
> http://code.djangoproject.com/wiki/DescriptorFields -- so you might
> have a look at that if you haven't already.
I have read that page - I didn't realize that it was actually
happe
On 12/29/05, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> I remember there being a good reason for this, but I don't recall the
> exact reason at this point... :-(
>
> At any rate, feel free to play around with a patch (and some
> accompanying unit tests) to see whether you can remove the
> table-
Hi all,
In working on the patch that was committed to magic-removal as r1792, I
noticed that there are some areas of test non-coverage in the
many-to-many processing section of parse_lookup. However, writing the
test cases is proving a little hairy, because I can't work out what the
correct behav
Hi again;
I've just added ticket #1143 to make parse_lookup implement the pre
r1792 behaviour of ManyToMany kwarg queries, and allow reverse queries
providing analogous behaviour.
While this fixes the immediate bug, it doesn't solve the larger
question of what constitutes correct behaviour.
You
Hi all,
What procedure should be followed if a patch to Django requires a new
i18n string?
I have run 'bin/make-messages.py -l en' to produce changes to the
English .po file. However, it concerns me that I needed to set
DJANGO_SETTINGS_MODULE - this implies that the script is adding i18n
strings
On 1/8/06, hugo <[EMAIL PROTECTED]> wrote:
So I would say: add translation strings to magic removal, but don't runmake-messages.py. Instead just run that after merging magic-removalback to trunk and so only have _one_ set of .po files.
Ok. I'll leave the po files alone.Thanks,Russ Magee %-)
Hi all,
I wanted to feel out opinion about two small, but theoretically
backwards-incompatible changes:
1) The DB query get_in_bulk() must be provided with an ID list. This
list can be provided _either_ as the first input argument, or in the
'id_list' kwarg (but not both). I would suggest the k
On 1/12/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
On 1/11/06, scum <[EMAIL PROTECTED]> wrote:> Could the comment tag be simplified to something like {! !} or {# #}.We've already got two different types of tags -- {% %} and {{ }} --
and introducing a third would be too complex for my tastes.Adr
Crap. Lets try this again without tabbing onto the send button.
On 1/12/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
On 1/11/06, scum <[EMAIL PROTECTED]> wrote:> Could the comment tag be simplified to something like {! !} or {# #}.We've already got two different types of tags -- {% %} and {{ }} -
On 1/13/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> I definitely understand why business logic should be kept out of the
> template; I don't see why adding AND/OR support is any worse than
> having if/if not/ifequal/ifnotequal/for.
>
> During the Snakes & Rubies talk it was mentioned that
On 1/15/06, Simon Willison <[EMAIL PROTECTED]> wrote:
>
> The current system in magic-removal enables multiple managers (you can
> assign as many as you like to different properties). I don't see the
> advantage in allowing this - why not just add wrapper methods to your
> custom Manager inner cla
On 1/18/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> This is a pretty nice idea. How would the syntax look in INSTALLED_APPS?INSTALLED_APPS = ('django.contrib.admin',('myapp.admin', 'myadmin'),)I'm +1 on this one; Existing behaviour is unaffected, new behaviour makes sense without bei
On 1/18/06, hugo <[EMAIL PROTECTED]> wrote:
>
> One thing I would agree to is, the default 'objects' is magic that
> should be removed. Actually that was my position in the discussion, to
> make the manager assignment _allways_ explicit, so people allways will
> choose the name of the manager obje
Hi all,
I've been looking at the code for normal object deletion in an attempt
to get the same behaviour for bulk delete. It seems like there is a
lot of logic dedicated to maintaining referential integrity that the
database could be doing (and would probably do more efficiently).
Is there any p
On 1/19/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 1/19/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> > It seems like most of the internal reference walking logic in the
> > object.delete() call would be eliminated if the foreign key fields
> >
On 1/20/06, hugo <[EMAIL PROTECTED]> wrote:
> BTW: the bulk delete stuff can be made more complete database-wise by
> using the delete sql clause to construct deletes against related tables
> (and doing updates against related tables).
I have no difficulty in seeing how it _can_ be done. However
Hi guys
Ok, lets try this one again.
I've attached (but not committed) a patch for bulk delete in
magic-removal (Ticket #1219).
Issues worth note:
- pre-delete/post-delete signals are sent for all deleted objects.
This could turn into a bit of a signal flood if you delete a lot of
objects, or
On 1/21/06, hugo <[EMAIL PROTECTED]> wrote:
> So I am +1 on that change,
I've attached an alternate version of the patch that implements this
idea. In this version, the object instance defers to the default
manager for delete functionality.
This removes the duplication of SQL delete logic, but
On 1/23/06, Ian Holsman <[EMAIL PROTECTED]> wrote:
I'd like to start moving my stuff over to the magic removal branch andwas wondering if the API is stable enough to start doing so.I would say probably not. There is still one big change to come - the use of descriptors on database objects. This wil
On 1/21/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> I've attached (but not committed) a patch for bulk delete in
> magic-removal (Ticket #1219).
Comments on this thread seem to have gone dead - are there any
objections out there to me committing this patch (the newer
On 1/26/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
>
> On 1/25/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> > Hmmm, that's the reverse lookup that was just recently added, right? I
> > guess it makes sense to change the tests...
> Place.objects.get_object(restaurants__place__exact=1) #
On 1/26/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 1/25/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> > Comments on this thread seem to have gone dead - are there any
> > objections out there to me committing this patch (the newer patch with
>
On 1/27/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> I'd suggest that m2m relations use the attribute name, and that we
> introduce an option for ForeignKey that lets you override the o2m name::
>
> class Article:
> writer = meta.ForeignKey(Reporter, related_name="articles")
>
On 1/27/06, hugo <[EMAIL PROTECTED]> wrote:
> >What happens to a query after it's been iterated? For example, how
> >does the following behave?
>
> I'd say it should memoize it's result - so it is only queried once per
> request to reduce database hits. But there should maybe a .reset()
> metho
On 1/27/06, Robert Wittams <[EMAIL PROTECTED]> wrote:
>
> Russell Keith-Magee wrote:
> > 2) I have a minor problem with the _set suffix: to me, _set implies
> > uniqueness in the returned results, which will not exist unless
> > .distinct()/distinct=True is used.
&g
On 1/27/06, Robert Wittams <[EMAIL PROTECTED]> wrote:
>
> > On the class itself, Article.objects(), Article.values(),
> > Article.in_bulk() become factory methods for producing Query objects
> > which, when iterated, provide objects of the expected type (instances,
> > dictionaries, etc).
>
> I've
On 1/27/06, Robert Wittams <[EMAIL PROTECTED]> wrote:
>
> Russell Keith-Magee wrote:
> > On 1/27/06, Robert Wittams <[EMAIL PROTECTED]> wrote:
> > It wasn't an attempt to be confusing.
>
> The intent does not change the effect.
Steady on soldier.
On 1/28/06, Robert Wittams <[EMAIL PROTECTED]> wrote:
> The only ones which will be shared are the ones which are the same
> object... which necessarily implies that the query/result set will be
> the same. The query specification in any particular "QuerySet" is
> immutable. The cache is just an
On 1/28/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> > My votes:
> >
> > 1. Model.objects
> > 2. instance.sites
> > 3. q.count()
> > 4. related_name: yes
+1 for 1,2,4.
On 3 I'm not completely convinced. I like the elegance/language symmetry of
len(Model.objects). I can see two possible objec
On 1/28/06, Luke Plant <[EMAIL PROTECTED]> wrote:
> On Saturday 28 January 2006 00:33, Russell Keith-Magee wrote:
>
> > - Secondly, the template language doesn't lend itself to making the
> > len(Model.objects) call.
>
> {{ objects|length }} works fine.
.
On 1/28/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> An implementation question, though: If foo.objects is a Manager
> instance, and accessing foo.objects returns a QuerySet instance, how
> would one access the other manager methods, such as
> foo.objects.get_pub_date_list(), etc.?
Isn't ge
On 1/28/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 1/27/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> > On 1/28/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> > > An implementation question, though: If foo.objects is a Manager
> >
Hi all,
I just ran the unit test suite on r2144, and noticed that there are
some unit tests failing as a result of some ChangeManipulator changes
around r2103. This is my first time spelunking in the Manipulator
code, so I'm not entirely sure if the problem is bad code, or a bad
test.
Specificia
On 1/29/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> I just saw http://code.djangoproject.com/changeset/2146 . Seems to me
> it'd be more efficient to do this in "manage.py validate" rather than
> at run-time.
Ah - I hadn't thought of putting it there. Change is on the way.
Russ Magee %-)
On 1/29/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 1/28/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> But note that
> manipulators are next on the list to be hacked-on (see the "making
> models validation-aware" thread on django-developers),
On 1/26/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> On 1/26/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> > Yeah -- I'm not 100% comfortable with coupling object instances to a
> > manager. It seems a bit wonky...
>
> I'll grant that the m
On 1/30/06, Luke Plant <[EMAIL PROTECTED]> wrote:
Yeah, I think you're right, I'm just aware that other people might beusing the Q() syntax already and have some use cases for it that I'munaware of. I haven't used it myself, and working on the setsthemselves seems fine for me.
I have a need - or,
On 1/31/06, Ian Holsman <[EMAIL PROTECTED]> wrote:
I'm looking to see how many other australians are interested inDjango, and also to get a list of people interested in some casualdjango work (if I get any) on the side.For the purposes of a census - I'm based in Perth.
I'm not really looking for c
On 2/10/06, limodou <[EMAIL PROTECTED]> wrote:
I'v summited a ticket http://code.djangoproject.com/ticket/1337 for this.What do you think about?-1 from me. The existing syntax is text-based, clear, concise, expressive, and pythonic (since it actually _is_ python).
If we introduce a new syntax fo
On 2/10/06, limodou <[EMAIL PROTECTED]> wrote:
On 2/10/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:>> The existing syntax is text-based, clear, concise, expressive, and pythonic
> (since it actually _is_ python).
I agree, but not very suit for automaticl tools. Do you l
Hi all,
Now that the dust has settled on the descriptor work, I've turned back
to bulk delete.
I've attached a new patch to the original ticket -
http://code.djangoproject.com/ticket/1219 - which is updated to
reflect the descriptor changes.
Notes:
1) As with the last version, the joins_allowe
On 2/6/06, Kuba Konczyk <[EMAIL PROTECTED]> wrote:
> I think this is too much.We only need to validate applications models
> that we want to install and maybe also core modules.
Hi Kuba,
Well spotted. This is a problem - however, the solution isn't quite as
simple as your patch, because you need
On 2/11/06, Luke Plant <[EMAIL PROTECTED]> wrote:
>
> On Saturday 11 February 2006 08:51, Russell Keith-Magee wrote:
>
> > Comments? Have I got it right this time?
>
> I think the main issue is whether we want methods
> that can alter data on the QuerySet directly
On 2/12/06, Robert Wittams <[EMAIL PROTECTED]> wrote:
> I was imagining that any call that created a new query set (ie modified
> some search parameter) would turn caching on. Of course, this wouldn't
> cache across calls that happened to end up with the same query. ( That
> would necessitate han
On 2/12/06, Robert Wittams <[EMAIL PROTECTED]> wrote:
You seem to have just repeated what I said .. I'm trying to work outwhat point you are making.I think I just got all turned around trying to follow the conversation - apologies for making you repeat yourself.
So basically the choices are:a) .al
On 2/13/06, Robert Wittams <[EMAIL PROTECTED]> wrote:
> Yes, this is exactly what I intended to convey... sorry if I didn't make
> myself clear...
It might take me few attempts to get the point, but as long as we all
end up on the same page... :-)
> > - q = Article.objects.filter(...).cached();
While all the cache talk is interesting and important, it is somewhat
separate from the original purpose of this thread: critique of the
bulk delete patch.
So far, the only criticism seems to revolve around the significance of
all(), and exactly how the cache works/should work. However, bulk
dele
On 2/14/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
This change, at a glance, looks good. Go ahead and commit it.Ok. Will do.
cached vs. non-cached query sets. The way it's currently handled inmagic-removal is great, and a fine improvement. Let's move forward. If this is the will of the gods, i
Hi Kuba,
I just added a patch for this to the magic-removal branch (as ChangeSet 2310).
Russ Magee %-)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to
On 2/18/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> So the question is, do we give the generated settings.py file all the
> possible settings, or does it continue to have just the settings that
> are commonly changed? I really could go either way on this.
Personally, I like the idea of setti
On 2/18/06, Maniac <[EMAIL PROTECTED]> wrote:
> It's good that current settings.py looks small. This adds to the feeling
> of perceived simplicity of Django. It is important because settings.py
> is one of the first things that new user sees.
How about putting all the essential configuration ite
Hi Luke,
On 2/19/06, Luke Plant <[EMAIL PROTECTED]> wrote:
>
> I think I've found a bug in bulk delete.
This looks very similar to a bug I have been chasing where the query
system mistakes a m2m field for a m2o field (because of names reported
by get_accessor_name()).
What SVN revision are you
On 2/22/06, Luke Plant <[EMAIL PROTECTED]> wrote:
- #1346 (and probably others)A quick heads up - I've been working on this one, and I've almost got it sorted out. Russ Magee %-)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Googl
On 2/19/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
>
> On 2/19/06, Luke Plant <[EMAIL PROTECTED]> wrote:
> >
> > I think I've found a bug in bulk delete.
>
> Other than that - I'll look into it.
Hi Luke,
I have put together a test case us
On 2/25/06, Luke Plant <[EMAIL PROTECTED]> wrote:
>
> On Friday 24 February 2006 23:34, Russell Keith-Magee wrote:
> > Can you confirm that your problem is also resolved?
>
> Thanks for working on this, but unfortunately it's still not resolved.
> However, I&#x
Hi all,
In working on an implementation for the remove() and clear() methods
for ManyRelatedObjectsDescriptor (i.e., mypolls.choices.remove() and
mypoll.choices.clear()), I have noticed that add() on a o2m
descriptor creates a new Choice object, whereas add() on a m2m
descriptor takes a list of
On 2/27/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> This sounds great to me. Go for it!
Ok - I've just committed these changes (r2409).
As a result of this commit, there is one more unit test failing - in
the many_to_one test, accessing new_article2.reporter.id seems to be
getting a stale
On 2/27/06, Luke Plant <[EMAIL PROTECTED]> wrote:
>
> How hard would it be to add the 'remove()' method but only for
> foreign key relationships that can be null?
That should be possible - I'll see what I can do.
Russ Magee %-)
--~--~-~--~~~---~--~~
You received
On 3/2/06, Kevin <[EMAIL PROTECTED]> wrote:
I'm trying to port my application over to the magic removal branch andran into this problem. My model for a shopping cart requires both ashipping and billing address, so I defined it as follows:class Sale(
models.Model):contact = models.ForeignKey(Co
On 3/2/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 3/1/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> > Obviously, this is a name clash, so the model validator complains.
>
> Russ, any way you can improve that error message to explicitly say
> &quo
On 3/2/06, Rock <[EMAIL PROTECTED]> wrote:
>
> My other changeset developed at this week's Django Sprint is much more
> extensive and is best explained by the new section that I am adding to
> the DB API docs.
>
> Feedback is welcome.
Truth be told, a desire to improve aggregates in Django is the
On 3/3/06, Luke Plant <[EMAIL PROTECTED]> wrote:
fields. For ManyToMany, you do: book.author.add(author1, author2...)I guess it would be good if the __set__ descriptor was there, and eitherdid the right thing or threw some exception.
I've been working with the descriptor protocol on RelatedManage
On 3/3/06, kmh <[EMAIL PROTECTED]> wrote:
Assigning a list implies assigning an order. How about:book.authors.set([author1, author2])
This doesn't address the problem - what is the 'set' behaviour of the descriptor protocol. The start of the _expression_ has to be 'book.authors ='; the question is
On 3/3/06, kmh <[EMAIL PROTECTED]> wrote:
If it were a 'set' method assignment would not be possible and anexception hinting to use 'set' would be raised. (Damn English language... setting the set with a set...)If I am understanding you correctly, you are opposed to having assignment notation for
On 3/3/06, kmh <[EMAIL PROTECTED] > wrote:
>
> My concern is that you end up with this:
>
> book.authors = [author1, author2]
> book.authors == [author1, author2] # not true
Well, if we want to get picky like that, then book.authors should
evaluate as a set as well, unless an order_by has been
On 3/3/06, xamdam <[EMAIL PROTECTED]> wrote:
>
> that sure did, it thanks! what is the best list to monitor these
> changes?
Your best bet would be to monitor changesets using the Timeline:
http://code.djangoproject.com/timeline
You can also get the timeline as an RSS feed if that is more your
On 3/4/06, Steven Armstrong <[EMAIL PROTECTED]> wrote:
>
> Hi django devs
>
> In a app I'm currently building I rely on the 'sqlinitialdata' feature.
> I've recently switched to the magical-removal branch where this is not
> yet implemented.
sqlinitialdata _was_ implemented, but it's been removed
On 3/4/06, Luke Plant <[EMAIL PROTECTED]> wrote:
> Russell (I think this is your area),
>
> I found another bug in delete(). I eventually managed to get it down to
> the attached example, in the same format as the existing model tests.
Thanks for narrowing this one down - I'll have a look at it.
On 3/4/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> OK, it's weirder than you think, though.
Oh.. I don't know... I think it's pretty weird :-)
> I get the same failure whether
> I run all the tests or only Luke's tests using postgreSQL (and
> everything passes with SQLite).
Thanks for
On 3/4/06, Luke Plant <[EMAIL PROTECTED]> wrote:
> But your patch fixes things for me - thanks!
Good to hear. I've committed it to magic removal as r2487. Thanks for
your (and Malcolm's) help in tracking this one.
> I haven't been able to find a nice solution. You can't even do
> something like
On 3/5/06, Luke Plant <[EMAIL PROTECTED]> wrote:
> Of course, with problems like stack limits I was encountering, you can't
> guarantee it will work for larger volumes of data, because it will
> depend on the size of 'many' in 'many-to-one', but for day-to-day usage
If you find another case that
On 3/2/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> Is it worth either fixing the attribute lookup to return None in the
> above case, or adding a self.source.exists attribute (returns true or
> false)? Then we can truly hide all references to source_id.
Hi Malcolm,
I'm in the process of
On 3/5/06, kmh <[EMAIL PROTECTED]> wrote:
>
> Russell Keith-Magee wrote:
> > We could get really carried away here, but I'm not sure if there is
> > any gain. The problem you are describing has existed since pre-MR days
> > (and can be seen living large in
Hi all,
A combination of recent tinkering with descriptors and a couple of
recent threads on mailing lists have collectively revealed a few
descriptor edge cases that do not appear to have been the subject of
any past discussion. This thread is an attempt to establish the
official behaviour for t
On 3/6/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> > 2) If a related attribute currently has a value of None, should the
> > __get__ method return None, or raise a DoesNotExist if accessed? Does
> > this behaviour change if the attribute is set null=True?
>
> I don't understand this, becau
On 3/7/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
>
> Russ, I can't thank you enough for your work on this stuff. Half
> these edge cases I wouldn't have even thought of 'til they bit me in
> the ass -- I really appreciate it :)
More than welcome. Being on the other side of the world makes
On 3/7/06, kmh <[EMAIL PROTECTED]> wrote:
>
> Thanks for the nice roundup. Votes may be in but just to clarify: my
> primary objection is that assignment is fundamentally a name-binding
> operation in Python and in this case what is bound to the name is not
> what is returned.
The fact that the
On 3/8/06, Rock <[EMAIL PROTECTED]> wrote:
It seems that no one else has any thoughts about this, so its just youand me.I read it to mean that everyone was concentrating on getting magic-removal finished. MR is all about getting the backwards incompatible changes out of the way in one big jump; on
On 3/9/06, Luke Plant <[EMAIL PROTECTED]> wrote:
>
> On Tuesday 07 March 2006 14:49, Russell Keith-Magee wrote:
>
> > > > 3) What is to become of the _id fields for ForeignKeys?
> > Isn't this covered by descriptor caching? One initial DB hit to ge
On 3/9/06, Max Battcher <[EMAIL PROTECTED]> wrote:
>
> Speaking of which: right now the Template engine isn't swallowing the
> Descriptor's DoesNotExist. I mentioned this and posted a patch:
Thanks, Max - I'll add this one to my todo list for this pass at
descriptor work.
Russ Magee %-)
--~--~
On 3/13/06, tomass <[EMAIL PROTECTED]> wrote:
Which is clunky but works okay, but what about if I have three other ifstatements for other variables? Do I nest those in, or is there someway to create a list or dictionary that holds all my lookup variables
(let's call it lookup_variables) and then I
On 3/14/06, Kieran Holland <[EMAIL PROTECTED]> wrote:
{% endif %}{# endif start_process #}I think comments should be encouraged in templates and the comment/endcomment tag set is almost prohibitively verbose at times. HTML has special tags for comments too, so I don't think it is too programmerish
On 3/13/06, Adrian Holovaty <[EMAIL PROTECTED]
> wrote:
Thoughts, criticisms? The only part I'm sketchy on is the side effectof converting the values to their Python data types. Thecleanliness/consistency is quite nice, but it's slightly not somethinga developer might expect. However, we can solve
On 3/17/06, Luke Plant <[EMAIL PROTECTED]> wrote:
> >>> len(connection.queries)
> 3
This is by design. Every call to all() produces a new query set. This
behaviour has been discussed a few times, usually in the context of
renaming all() 'cached()', whether caching should be the default or an
opti
On 3/18/06, Eugene Lazutkin <[EMAIL PROTECTED]> wrote:
>
> Why don't we use something simple, like tuples:
>
> pubdate=('year', 2005)
> name='John' (it is possible now)
> fname=('contains','n')
Interesting, but I'm not sure I see the advantage. I don't think this
notation is inherently more obvio
On 3/21/06, ak <[EMAIL PROTECTED]> wrote:
>
> I wrote a small path to fix this problem. Does anyone need it ? Where
> should I post it ?
Hi Anton,
If you have found a bug, log a ticket at
http://code.djangoproject.com/newticket, and mark the issue as a
defect.
Before you log your bug, have a qu
On 3/24/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
I'm really asking about something more abstract, though -- is there(should there be) the ability to define manager methods availableonly in a related context?+1 to this idea. The managers used by object descriptors already have this problem,
On 3/27/06, John Szakmeister <[EMAIL PROTECTED]> wrote:
> I'm trying to get up and running with the magic removal branch and ran into my
> first snafu. It turns out the sqlall command didn't quite work. Turns out
> it was an easy fix though (if the patch is correct). I've attached a patch
> for
On 4/4/06, Seth Falcon <[EMAIL PROTECTED]> wrote:
Hi,I'm just getting started with django and worked through the tutorialusing the magic-removed branch.I made some fixes based on info found on the wiki to make the tutorialwork. Wondering if someone would like the diffs.
Sure would! Attach them to
On 4/4/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> Jacob: is there something wrong with this, or is it just unloved?
I can't speak for Jacob, but I'm pretty sure its just been lost in the
flood. I know it is frustrating, but quite often the rate of patch
production exceeds the rate at w
On 4/14/06, Rob Shakir <[EMAIL PROTECTED]> wrote:
> I've just started using django today for a internal project, which
> centres around network management. I notice that there was no support
> for the cidr PostgreSQL datatype, and so I've added it. Please find the
> diff attached.
Thanks for the
On 4/15/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> Any huge objections?
+1 from me.
-0 on the 'default' lookup option proposed. The only benefit I can see
to having the extension optional is during the 0.91->MR transition
phase, where you have template calls that haven't been updated.
R
On 4/14/06, Rob Shakir <[EMAIL PROTECTED]> wrote:
>
> Thanks for the comments - I'll update the patch to add documentation
> entries.
Don't feel like you can't buck the trend and add unit tests, too :-)
> Whilst I can see the point ref: adding support for datatypes that aren't
> supported formal
Hi all,
In working through the Model API documentation, I came across the
'singular' argument for m2m fields. Since we have removed the
pluralization parts of Django, it seems to me that `singular` is no
longer required.
Does anyone have any objections to me removing this argument, or is
there a
On 4/21/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
Timeline: Let's aim for a merge on next Friday, April 28. That shouldgive us enough time to work on documentation and iron out last-minutebugs.Huzzah! A collective thanks to all involved in getting this beast off the ground, and those in the us
On Wed, Nov 16, 2011 at 5:12 PM, Roald wrote:
> Hi all,
>
> Can anybody explain why template tag libraries are loaded from
> *inside* a template? The more I work with them, the more I get the
> feeling that specifying which template tags are available in a
> template should be specified in the vie
On Sat, Nov 19, 2011 at 4:08 PM, Cal Leeming [Simplicity Media Ltd]
wrote:
> Hi,
> Since the release of 1.3, Django has changed the way it generates the
> memcache key name.
> If I was to do:
> cache.set('hello', 'world', 300)
> It would actually store the result as ":1:hello". Obviously, this is
On Saturday, November 19, 2011, Cal Leeming [Simplicity Media Ltd] <
cal.leem...@simplicitymedialtd.co.uk> wrote:
> Thanks for the reply Russ.
> I think ultimately it comes down to the fact that it was difficult to
figure out what was happening, where as the actual fix itself (as you
mentioned belo
On Fri, Nov 25, 2011 at 12:27 PM, Jawaad Mahmood
wrote:
> On Nov 25, 10:53 am, Arthur Fortes wrote:
>> Hello, I'm new in Django and I got a problem with a formwizard. My
>> manytomany dont works with formwizard. When I try appears this error :
>> 'areaes' is an invalid keyword argument for this f
2011/11/27 Mikołaj Siedlarek :
> Hi,
> I've just posted a new ticket with everything the feature proposal needs -
> motivation, idea and actual implementation.
> https://code.djangoproject.com/ticket/17301
>
> It definitely needs some discussion, so please -- ask, discuss, criticize,
> share some t
1001 - 1100 of 2850 matches
Mail list logo
