Russell Keith-Magee wrote:
> On 10/13/07, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
>> I know the argument list for form_for_model is getting long, but
>> excluding fields is just so damn useful ;)
>
> +1 from me. Personally, I'm in favour of making form_for_model as
> flexible as possible.
I had wondered at the time if it was better to just add the PK as an
argument to the post_delete dispatch, rather than having it available
on the object itself. Something like "old_pk" I suppose. I didn't have
any interest in it at the time though, so I left the discussion to
those who actually
On Mon, 2007-10-15 at 18:02 -0500, Jacob Kaplan-Moss wrote:
[...]
> I'm really not opposed to changing the behavior again -- I was at most
> +0 on keeping the PK around -- but only if there's a good alternative.
Not worth it. There's enough legitimate churn going on without us
second-guessing
On 10/15/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> Relax, dude. I'm not going to change anything. Queryset-refactor used
> the pre-change behaviour -- I meant to say I'm changing it "back" to
> match current trunk. I hadn't noticed the recentness of the trunk change
> because of
On Mon, 2007-10-15 at 17:50 -0500, Jacob Kaplan-Moss wrote:
> On 10/15/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> > I don't completely like that change -- since I don't think unsaved
> > things should ever have a pk value in user code unless the user
> > explicitly set it -- but it's
On Mon, 2007-10-15 at 17:32 -0500, Jeremy Dunck wrote:
> On 10/15/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> > Barring any good reason, I want to change _get_data() back to being an
> > iterator. A whole bunch of things become easier if we do that.
> >
> > But nothing happens without a
On 10/15/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> I don't completely like that change -- since I don't think unsaved
> things should ever have a pk value in user code unless the user
> explicitly set it -- but it's survivable. I'll change queryset-refactor
> back.
Wait... wait a
On Mon, 2007-10-15 at 18:23 -0400, Karen Tracey wrote:
> I think perhaps it is the behavior on trunk that has changed, in
> response to this thread:
>
> http://groups.google.com/group/django-developers/browse_thread/thread/2fc1726ce70fc92b
Ahh, nice find. So it was very recent and during a
On 10/15/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> Barring any good reason, I want to change _get_data() back to being an
> iterator. A whole bunch of things become easier if we do that.
>
> But nothing happens without a reason, so if the keepers of the
> institutional memory could
I think perhaps it is the behavior on trunk that has changed, in response to
this thread:
http://groups.google.com/group/django-developers/browse_thread/thread/2fc1726ce70fc92b
Karen
--~--~-~--~~~---~--~~
You received this message because you are subscribed to
On 10/15/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> So, is there a reason for the current behaviour? I would have dismissed
> it as a bug on trunk except for the test that means somebody took the
> effort to think about the current behaviour and assert it's logical.
Cache invalidation?
Ian Kelly wrote:
> On 10/15/07, Carl Karsten <[EMAIL PROTECTED]> wrote:
>> Who has recently worked on django/db/backends/oracle code? I have some tips
>> from the author of the oracle dbapi module. I am not actualy working with
>> oracle, so it makes no sense for me to go changing code.
>>
>>
In trunk, if you call obj.delete() where 'obj' is a model instance, the
post_delete signal is emitted whilst 'obj' still has a primary key value
set, even though it's already been deleted from the database.
Interestingly, we also test for this behaviour (in
modelstests/signals/models.py). So it
Question for the Django Ancient Ones..
In current trunk's QuerySet.__iter__ method we do:
return iter(self._get_data())
and _get_data() is basically (module some caching checks):
return list(self.iterator())
Now, iterator() really is an iterator. So the effect of all
I think a decent solution here would be to for somebody to write a
helper function with the purpose of merging multiple forms in the way
people seem to expect multiple inheritance to work. It wouldn't be
part of Django proper, I imagine, but it would make a useful snippet
to pass around when
On Oct 15, 7:42 am, Tobias Bender <[EMAIL PROTECTED]> wrote:
> Am I doing something wrong or is this a bug?
Hi Tobias,
You are running into a form_for_model bug[1]. SmileyChris has tried
to address this in [2], but his solution met with a little resistance
on Trac, with the final comment being
On 10/15/07, Carl Karsten <[EMAIL PROTECTED]> wrote:
>
> Who has recently worked on django/db/backends/oracle code? I have some tips
> from the author of the oracle dbapi module. I am not actualy working with
> oracle, so it makes no sense for me to go changing code.
>
> Carl K
>
> >>> 2. you
Who has recently worked on django/db/backends/oracle code? I have some tips
from the author of the oracle dbapi module. I am not actualy working with
oracle, so it makes no sense for me to go changing code.
Carl K
>>> 2. you do cx_Oracle, right? If so, I am wondering if this is the best
Actually, I don't want a 404, just to pass 'None' in as the value for
"object".
On Oct 12, 10:31 am, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote:
> On 10/12/07, Joe <[EMAIL PROTECTED]> wrote:
>
>
>
> > I don't know how many times I've wanted to to this:
>
> > return
On Wed 10 Oct 2007, Peter Nixon wrote:
> Hi Guys
>
> I am running into the problem that uniqueness is not enforced at the ORM
> layer. From:
> http://www.djangoproject.com/documentation/model-api/#unique
>
> "This is enforced at the database level and at the Django admin-form
> level."
>
> This
On 10/15/07, akaihola <[EMAIL PROTECTED]> wrote:
>
> Am I correct in my conclusion that formset_for_model() in the newforms-
> admin branch doesn't offer any convenient way to define the form's
> prefix?
You define a prefix when you instantiate the FormSet, not when you
define the class. It
On 10/11/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
>
> I think you're completely right about making the exception handler
> into a plain old view; the signature (request, exception) seems right,
> but I haven't thought it through completely yet.
I'd imagine that (request, exc_class,
Hi.
I have tried something like that:
class MyForm(form_for_model(Model_A), form_for_model(Model_B)):
...
myform = MyForm()
but the resulting myform.as_table() contains the fields which are from
form_for_model(Model_A) only. When changing the class MyForm to class
Am I correct in my conclusion that formset_for_model() in the newforms-
admin branch doesn't offer any convenient way to define the form's
prefix?
Is my best option currently to subclass BaseModelFormSet and override
the defalt value of the prefix= kwarg in its __init__()?
If so, wouldn't it
24 matches
Mail list logo
