Ciao Djangonauts™,
2006/1/26, Adrian Holovaty <[EMAIL PROTECTED]>:
> I've written up my latest proposal here:
> http://code.djangoproject.com/wiki/DescriptorFields
Sorry if I'm late again, but I'm wondering...
why does QuerySet objects doesn't have
the methods all(), dates(), in_bulk() and values
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
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
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
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
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")
>
>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
On 1/26/06, Robert Wittams <[EMAIL PROTECTED]> wrote:
>
> Joseph Kocherhans wrote:
> > On 1/26/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >
> >>I'm not a fan of .all() either - if you can do .filter() on
> >>Article.objects, then surely Article.objects is already a collection of
> >>some k
On Thursday 26 January 2006 23:45, Joseph Kocherhans wrote:
> Let's assume that MyModel.objects or my_object.related_set *IS* a
> Query object (in other words, it has state):
It's state is simply an empty set of where clauses and an empty order by
list and these never actually change.
> q = MyM
Joseph Kocherhans wrote:
> On 1/26/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
>>I'm not a fan of .all() either - if you can do .filter() on
>>Article.objects, then surely Article.objects is already a collection of
>>some kind. That's what is sounds like: Article.objects == all the
>>'Art
On 1/26/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> I'm not a fan of .all() either - if you can do .filter() on
> Article.objects, then surely Article.objects is already a collection of
> some kind. That's what is sounds like: Article.objects == all the
> 'Article' objects.
And there's
This is great, but one remaining issue:
If the related objects lookups always use the corresponding manager,
then this:
> article_obj.reporter
would be equivalent to:
> Reporter.objects.get(pk=article_obj.id)
That can throw a Reporter.DoesNotExist exception, which might not just
be corner cas
I'm not a fan of .all() either - if you can do .filter() on
Article.objects, then surely Article.objects is already a collection of
some kind. That's what is sounds like: Article.objects == all the
'Article' objects.
Also, if Query instances act as sets, they should support len(), and
you don't
Jacob Kaplan-Moss wrote:
> class Article:
> writer = meta.ForeignKey(Reporter, related_name="articles")
> sites = meta.ManyToManyField(Site)
>
> s = Site.objects.get(pk=1)
> r = Reporter.objects.get(pk=1)
>
> s.article_set.all()
> r.articles.all()
>
> That is
On 1/26/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> It seems to me that the translation from ``sites`` in the model to
> ``site_set`` in the instance is "worse" than having an inconsistency
> between m2m and o2m relations. In fact, I don't really have a
> problem with the two relation typ
On Jan 26, 2006, at 10:28 AM, Adrian Holovaty wrote:
The reason is consistency. If we enforce the "_set" thing (or whatever
other name we come up with), that means there's a simple rule to
remember:
[snip]
Make sense? But, yeah, I realize that the "sites" attribute name in
that model is essent
hugo wrote:
> One nice thing about chained methods is, you can pass around the query
> object and modify it after the fact. Think "curried queries" - you
> build a partial query and pass it to a function, which itself can add
> more query specifications or ordering or stuff like that, without
> ne
On 1/25/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> > Also, it would be cool if the _set stuff wasn't forced on us, there's
> > a disconnect between creating an attribute called 'sites' in your
> > model, and accessing that attribute via 'site_set'.
>
> I *very* much agree with this.
>
> Co
On Jan 26, 2006, at 2:23 AM, hugo wrote:
One nice thing about chained methods is, you can pass around the query
object and modify it after the fact. Think "curried queries" - you
build a partial query and pass it to a function, which itself can add
more query specifications or ordering or stuff
Adrian Holovaty wrote:
> I've written up my latest proposal here:
>
> http://code.djangoproject.com/wiki/DescriptorFields
>
> It turns out related-object lookup can cleanly use the manager API.
> Thoughts? If there are no big objections, let's start converting the
> magic-removal unit tests to u
>Good call about the "sites" thing. Really, that attribute name isn't
>used at all (from what I can tell)...hmmm. What are your ideas?
Regardless of what you do in the end: please no "magic name invention",
especially if it is something like "attribute sites becomes site_set" -
that way we would
>I'm a big fan of the "One True Way" principle, so that rubs me the
>wrong way. Why not simply have order_by/distinct/etc. be kwargs to
>the manager functions? If there's a good reason to do the "chained
>methods" that's fine, but let's not be too clever for our own sakes, eh?
One nice thing ab
On Jan 25, 2006, at 9:57 PM, Adrian Holovaty wrote:
I've written up my latest proposal here:
http://code.djangoproject.com/wiki/DescriptorFields
Yum!
I agree with Joseph -- I like this new syntax a *lot*.
I do have a few semantic questions, though. WARNING: Much nit-
picking follows; I sh
On 1/25/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 1/25/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
>
> > Also, it would be cool if the _set stuff wasn't forced on us, there's
> > a disconnect between creating an attribute called 'sites' in your
> > model, and accessing that attrib
On 1/25/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> One question though... it doesn't say anything about accessing fields
> via the class anymore. Is that still the plan? Article.sites,
> Article.reporter, etc would return the field object, and
> article_obj.site_set returns a manager.
Yea
On 1/25/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> I've written up my latest proposal here:
>
> http://code.djangoproject.com/wiki/DescriptorFields
>
> It turns out related-object lookup can cleanly use the manager API.
> Thoughts? If there are no big objections, let's start converting the
I've written up my latest proposal here:
http://code.djangoproject.com/wiki/DescriptorFields
It turns out related-object lookup can cleanly use the manager API.
Thoughts? If there are no big objections, let's start converting the
magic-removal unit tests to use this new syntax, and I'll start
im
... also, what happens about exceptions i.e. when do they get thrown?
This applies to all the lazy collections, and also foreign key relationships:
e.g. from the wiki:
> article.reporter
> article.reporter.id (Doesn't do a DB query)
The first could throw Reporter.DoesNotExist, but the secon
On Wed, 25 Jan 2006 11:46:09 -0600 Adrian Holovaty wrote:
> If managers behaved like that, how would one do the equivalent of
> get_object()?
... and get_values() (which doesn't fit the 'sets' paradigm at all,
since it can contain duplicates)?
The original proposal was only for model instance a
On 1/25/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 1/25/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> > If this were the case then it would be impossible to combine filter
> > and order_by, at least in this way:
> >
> > MyModel.objects.filter(creator__exact=5)
> > MyModel.objects.o
On 1/25/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 1/25/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> > Is anyone planning on tackling the descriptor fields proposal anytime
> > soon? If not, I can give it a shot.
>
> I was planning on starting this last night but got wrapped up in
On 1/25/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> If this were the case then it would be impossible to combine filter
> and order_by, at least in this way:
>
> MyModel.objects.filter(creator__exact=5)
> MyModel.objects.order_by('status')
> for obj in MyModel.objects:
> print obj
>
> F
On 1/25/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> On 1/25/06, Jason Davies <[EMAIL PROTECTED]> wrote:
> >
> >
> > Joseph Kocherhans wrote:
> >
> > > At any rate, Managers and ManyToMany/OneToMany attributes do extremely
> > > similar things, and I think they could share an api and maybe e
On 1/25/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> Is anyone planning on tackling the descriptor fields proposal anytime
> soon? If not, I can give it a shot.
I was planning on starting this last night but got wrapped up in other
stuff. I'd like to start on it myself later this evening.
On 1/25/06, Jason Davies <[EMAIL PROTECTED]> wrote:
>
>
> Joseph Kocherhans wrote:
>
> > At any rate, Managers and ManyToMany/OneToMany attributes do extremely
> > similar things, and I think they could share an api and maybe even
> > share most implementation. If managers behaved like object attr
Joseph Kocherhans wrote:
> At any rate, Managers and ManyToMany/OneToMany attributes do extremely
> similar things, and I think they could share an api and maybe even
> share most implementation. If managers behaved like object attributes,
> this is what I'm worried about:
>
> MyModel.objects.fi
Is anyone planning on tackling the descriptor fields proposal anytime
soon? If not, I can give it a shot.
I'm not entirely clear as to how to do the ManyToMany and the
auto-generated end of the ForeignKey fields yet. It really feels like
they should just return a Manager instance (that automatica
57 matches
Mail list logo
