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
> > instance, and accessing foo.objects returns a QuerySet instance, how
> > would one access the other manager me
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, 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.
... as Russell manages to completely forget
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.
If you wanted it in an 'if' tag (ie. if length = some value), then you
can't do the above, but you can
I've implemented the very first bit of descriptor fields -- the bit
that does poll.choice_set instead of poll.get_choice_list().
http://code.djangoproject.com/changeset/2141
Just before that, I'd added a core_filters attribute to Managers,
which, if set, is applied to every data-access query for
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
Brant Harris wrote:
> Reporter.objects.order_by('-lname', 'fname') is incorrect as far as I
> can see. The manager cannot hold this state info.
You appear to have misinterpreted the proposal then. There is a limit to
how many times the same argument can be repeated... please, reread the
thread.
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
Luke Plant wrote:
> On Friday 27 January 2006 22:25, Joseph Kocherhans wrote:
>
>
>>1. Model.objects vs. Model.objects.all()
>>(and also instance.sites vs. instance.sites.all()?)
>
>
> +1 on Model.objects and instance.sites
+1
>>2. len(q) vs. q.count()
>
>
> Actually, can we get away wi
This is all crazy. You people are crazy.
I figured this out months ago:
http://code.djangoproject.com/ticket/980, we didn't have the concept
of the manager back then, of course, but the basic principles are
there, (query == filter).
If you cache the count, len() and bool() can be called over an
On Friday 27 January 2006 22:25, Joseph Kocherhans wrote:
> 1. Model.objects vs. Model.objects.all()
> (and also instance.sites vs. instance.sites.all()?)
+1 on Model.objects and instance.sites
> 2. len(q) vs. q.count()
Actually, can we get away with not having len(q)? If you try to use a
On 1/27/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> > 1. Model.objects vs. Model.objects.all()
> > (and also instance.sites vs. instance.sites.all()?)
> >
> > 2. len(q) vs. q.count()
> >
> > 3. related_name for ForeignKey and ManyToManyField
> > related_name defaults to OBJECT_set i
On Jan 27, 2006, at 4:25 PM, Joseph Kocherhans wrote:
I think that's the main point of disagreement. Does this capture it
all?
1. Model.objects vs. Model.objects.all()
(and also instance.sites vs. instance.sites.all()?)
2. len(q) vs. q.count()
3. related_name for ForeignKey and ManyToMa
On 1/27/06, Maniac <[EMAIL PROTECTED]> wrote:
>
> Adrian Holovaty wrote:
>
> >So what did we decide to change from the current proposal at
> >http://code.djangoproject.com/wiki/DescriptorFields ? I got lost. :)
> >
> >
> The best I can conclude is that the only difference with this page is
> that
Adrian Holovaty wrote:
So what did we decide to change from the current proposal at
http://code.djangoproject.com/wiki/DescriptorFields ? I got lost. :)
The best I can conclude is that the only difference with this page is
that people don't like the ".all()" thing and want Manager to behave
On 1/27/06, Tom Tobin <[EMAIL PROTECTED]> wrote:
> That raises a wider question: do we want to singularize those field
> names as well? It's more of a cosmetic issue, as it doesn't affect
> the core of the table-name-generating code -- but it would induce more
> breakage as applied to the various
So what did we decide to change from the current proposal at
http://code.djangoproject.com/wiki/DescriptorFields ? I got lost. :)
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com | chicagocrime.org
On 1/27/06, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
>
> I haven't been following the magic removal branch closely, but here:
> http://code.djangoproject.com/wiki/RemovingTheMagic
>
> There is a migration script for mysql. This line looks wrong:
> ALTER TABLE auth_groups_permissions RENAME TO auth
Russell Keith-Magee wrote:
From my context, Article.objects() constructs a basic query that knows
how to return all object instances of type Article, which can then be
filtered to produce more complex query objects. The idea that there is
a single basic query which everyone should use doesn't r
>>>and how do you reset it?
>>
>>I think this is a legitimate need, and one that can be simply supported
>>with a clear_cache() method on QuerySet or whatever.
> The problem is I've been thinking of Article.objects() where the
> return value is an object representing an instance of a _query_, whi
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. Just because I disagree with you doesn't
_necessar
On a related note, there's a typo in django.contrib.auth.models in
magic-removal - see http://code.djangoproject.com/ticket/1276
Regards,
Jason
On 1/27/06, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
> There is a migration script for mysql. This line looks wrong:
> ALTER TABLE auth_groups_permissions RENAME TO auth_group_permissions;
>
> Rename to the same name?
> Perhaps:
> ALTER TABLE auth_groups_permissions RENAME TO auth_group_permission
I haven't been following the magic removal branch closely, but here:
http://code.djangoproject.com/wiki/RemovingTheMagic
There is a migration script for mysql. This line looks wrong:
ALTER TABLE auth_groups_permissions RENAME TO auth_group_permissions;
Rename to the same name?
Perhaps:
ALTER TA
Russell Keith-Magee wrote:
> 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,
>>>di
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
Joseph Kocherhans wrote:
> Ian Bicking has kept len() out of SQLObject result sets even though it
> seems really intuitive to use. Here's a rundown of what I remember
> about his argument: __len__ would run "count (*)" against the db. I
> think iter() calls len() implicitly for performance reason
Russell Keith-Magee wrote:
> 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.
>>
>
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.
>
> Could you provide an example w
> Taking this approach a little further, it could also address Adrian's
> Manager __call__ problem with Jacob's Article.objects() proposal.
> Rather than exposing the manager itself, expose an interface that can
> be used as a factory for producing Query objects. Keep the Manager
> internally as
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
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. Either distinct needs to be turned
> on by default and disabled by parameter/filter (which I have
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 Wednesday 25 January 2006 18:15, Daniel Poelzleithner wrote:
> Jeremy Dunck wrote:
> > This makes me think the world needs a wiki whose wikitext syntax is
> > restructured text.
>
> In general ?
> At least trac has a macro for restructured text I think.
Yes, it does:
http://projects.edgewall
>Ah, interesting -- I hadn't thought about that situation. So
>essentially a Query is a curried lookup until you iterate it, yes?
Yep.
>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
35 matches
Mail list logo
