On Mar 4, 1:53 pm, Alex Gaynor wrote:
> On Mar 4, 2009, at 8:29 AM, PauloS wrote:
>
> The only other obvious thing is that you should test:
> if queryset is not None
>
I will get there someday:
8<--
if queryset is None:
queryset = self.model._default_mana
On Mar 4, 2009, at 8:29 AM, PauloS wrote:
>
> On Mar 3, 1:55 pm, Alex Gaynor wrote:
>> Looking at the patch IMO it should still dot he
>> filter(**{self.fk.name:
>> self.instance.pk}) even if you provide a queryset.
>
> You are right again. Would you mind to look again and give any advice
>
On Mar 3, 1:55 pm, Alex Gaynor wrote:
> Looking at the patch IMO it should still dot he filter(**{self.fk.name:
> self.instance.pk}) even if you provide a queryset.
You are right again. Would you mind to look again and give any advice
(I'm as crude in python as in English).
Thanks!
--~--~--
On Tue, Mar 3, 2009 at 11:50 AM, PauloS wrote:
>
> On Mar 2, 3:23 pm, Alex Gaynor wrote:
> > > I'm happy with this. Can I start writing a patch?
> >
> > He who has the patch has the power :)
>
> Atached to ticket #10263.
>
> With this change I was able to write a neat spreadshet-like interface
>
On Mar 2, 3:23 pm, Alex Gaynor wrote:
> > I'm happy with this. Can I start writing a patch?
>
> He who has the patch has the power :)
Atached to ticket #10263.
With this change I was able to write a neat spreadshet-like interface
with filtering and ordering.
--~--~-~--~~
On Mon, Mar 2, 2009 at 12:41 PM, PauloS wrote:
>
> >
> > Firstly there is no reason for the _factory functions to take a queryset
> > argument, the queryset is specific to the formset instance, not the class
> > itself. Secondly in no way are 2 arguments more consistant than a single
> > queryse
>
> Firstly there is no reason for the _factory functions to take a queryset
> argument, the queryset is specific to the formset instance, not the class
> itself. Secondly in no way are 2 arguments more consistant than a single
> queryset argument, because once we add filter someone will request
On Sun, Mar 1, 2009 at 2:31 PM, PauloS wrote:
>
> > Perhaps I'm not making myself clear, but it ALREADY take a queryset
> > argument:
>
> Alex, I know this, but last time I checked BaseInlineFormSet does not.
> Same case with *formset_factory helper functions. It's clear why not,
> it's because t
> Perhaps I'm not making myself clear, but it ALREADY take a queryset
> argument:
Alex, I know this, but last time I checked BaseInlineFormSet does not.
Same case with *formset_factory helper functions. It's clear why not,
it's because these helper functions are supposed to build the queryset
for
Of course not - you can do .order_by() to clear ordering if you really
don't want a default ordering somewhere, but all your examples sound
like you do :)
On Sat, Feb 28, 2009 at 3:02 PM, PauloS wrote:
>
> On Feb 27, 5:28 pm, Collin Grady wrote:
>> One could also set a default ordering on a mod
On Sat, Feb 28, 2009 at 6:34 PM, PauloS wrote:
>
> InlineFormSet is perfect to build spreadsheet-like grid interfaces,
> but for a good user experience the form elements need to have
> consistent order across GET-after-POST cycles. Currently this happens
> BY ACCIDENT in most SGBD backends, and I
InlineFormSet is perfect to build spreadsheet-like grid interfaces,
but for a good user experience the form elements need to have
consistent order across GET-after-POST cycles. Currently this happens
BY ACCIDENT in most SGBD backends, and I think relying on accidents is
bad programming style.
The
On Feb 27, 5:28 pm, Collin Grady wrote:
> One could also set a default ordering on a model and have a consistent
> order everywhere :)
This way you have to pay the ORDER BY price for every query?
--~--~-~--~~~---~--~~
You received this message because you are subs
2009/2/27 Collin Grady
>
> One could also set a default ordering on a model and have a consistent
> order everywhere :)
>
I personally agree with this one, the issue at hand is because of 'bad
programming' in my opinion and shouldn't be solved internally by django
(certainly if the fix isn't tri
One could also set a default ordering on a model and have a consistent
order everywhere :)
--
Collin Grady
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send emai
On Fri, Feb 27, 2009 at 1:21 PM, PauloS wrote:
>
> Hi,
>
> I have a related patch (#10263).
>
> I have an application where I rendered my inline forms like an
> spreadsheet, the effect when the user saves the form and the row order
> changes is very unpleasant. This bug does not show up often bec
Hi,
I have a related patch (#10263).
I have an application where I rendered my inline forms like an
spreadsheet, the effect when the user saves the form and the row order
changes is very unpleasant. This bug does not show up often because
most databases other than Postgres return unordered queri
On Thu, 2009-02-26 at 12:56 +0100, Killian wrote:
> Anyway, I'm wondering what's the use of explicitly indexing the
> objects in an unordered queryset? When it's unordered, the result
> you'll get is random anyway, you cannot predict the outcome at all.
> The only reason I see is to select multipl
Anyway, I'm wondering what's the use of explicitly indexing the objects in
an unordered queryset? When it's unordered, the result you'll get is random
anyway, you cannot predict the outcome at all. The only reason I see is to
select multiple 'random' objects, which is much easier solved by
order_by
On Feb 25, 10:08 pm, Jacob Kaplan-Moss
wrote:
> See, the reason I closed your ticket as wontfix is because I don't
> think there is. That is, I think it's impossible to make
> ``unordered_qs[N] == unordered_qs[N]`` 100% of the time without (a)
> adding an artificial ``ORDER BY`` clause or (b) mat
On Wed, Feb 25, 2009 at 10:08 PM, smoluf wrote:
> I think there is a way to remedy my complaint without destroying any
> of the current behavior that you outlined (and without sacrificing
> performance).
See, the reason I closed your ticket as wontfix is because I don't
think there is. That is,
> Personally I think this is useful behavior for two reasons:
>
> 1. You get results which, when possible, represent the latest state of
> your database, as opposed to a view into what your database looked
> like back when the query was run.
This is true, but the suggested fix (assign an ar
On Wed, Feb 25, 2009 at 10:04 PM, smoluf wrote:
> If I issue an equivalent query with a QuerySet, however, and then
> select two rows by indexing into the result at two random locations, I
> can not currently be guaranteed that they are different rows because
> the QuerySet will use two different
Hey guys. First I want to apologize for re-opening the ticket, a bit
of a ready-fire-aim moment there. However, I would like to make my
case for the ticket here in a complete way.
I think this is a case of conflating two issues, so I hope I can
separate them and convince you that one of them actu
24 matches
Mail list logo
