On 1/27/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
I answered your question in another thread:http://groups.google.com/group/django-users/browse_thread/thread/0a7b94b58722470b/d378ce32a02d53ba
Thanks a lot Adrian.-- Amit UpadhyayBlog: http://www.rootshell.be/~upadhyay+91-9867-359-701
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
Joseph Kocherhans wrote:
> Is this a good summary of the current thinking on subclassing?
>
> http://groups.google.com/group/django-developers/browse_frm/thread/ea5e0bf903058fac/9a68ac0d99cb6d7d?q=semantics&rnum=1#9a68ac0d99cb6d7d
>
> The wiki doesn't say a whole lot about it, although it's prob
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
On 1/26/06, Robert Wittams <[EMAIL PROTECTED]> wrote:
>
> I think all that is needed here is education - it needs to be pointed
> out what the costs of subtyping are.
I agree. I think most of the time the join is going to be simple
anyhow... take comments for instance. Say I have a Comment class
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
On 1/21/06, Amit Upadhyay <[EMAIL PROTECTED]> wrote:
> I am trying to generate RSS feeds using Django, and followed the
> documentation, but am not able to figure out how to specify title and
> description for individual items. Right now Django is using the string
> representation of item objects.
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
Maniac wrote:
>
> Joseph Kocherhans wrote:
>
>> http://code.djangoproject.com/wiki/ModelInheritance
>>
>> This is still really rough. I hope I didn't leave too much out. Let
>> the arguing commence ;-)
>>
>>
> If the last bit ("Change the current usage of subclassing") is only
> about removing
> app_objects = managers.PolymorphicManager(Place, Restaurant,
> ItalianRestaurant)
> ``
>
> This also makes it explicit which classes are participating in a join,
> rather than potentially joining a large number of installed model classes.
>
Thus making it completely unnatural to inherit from
Maniac wrote:
Jacob Kaplan-Moss wrote:
If I ask for places, give me a list of places and don't bother
looking up restaurants. So:: ``place_instance.description`` should
raise an ``AttributeError`` regardless if weather or not it is
actually a restaurant.
Why? This is not how duck typ
Jacob Kaplan-Moss wrote:
> 1. Modeling parent relations in SQL: #3 seems to make the most sense
> for me -- I can't think of a case in a one2one where the child id would
> need to differ from the parent id. Also::
>
> CREATE TABLE "myapp_restaurant" (
> "id" integer NOT NULL PRIMA
Joseph Kocherhans wrote:
http://code.djangoproject.com/wiki/ModelInheritance
This is still really rough. I hope I didn't leave too much out. Let
the arguing commence ;-)
If the last bit ("Change the current usage of subclassing") is only
about removing inherited attributes why not do it th
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
Jacob Kaplan-Moss wrote:
If I ask for places, give me a list of places and don't bother
looking up restaurants. So:: ``place_instance.description`` should
raise an ``AttributeError`` regardless if weather or not it is
actually a restaurant.
Why? This is not how duck typing works all ov
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 12:26 PM, Joseph Kocherhans wrote:
http://code.djangoproject.com/wiki/ModelInheritance
Thanks for doing this, Joseph! It looks really good, too, but here
are the (inevitable) nitpicks:
1. Modeling parent relations in SQL: #3 seems to make the most sense
for me -- I c
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
I talked to Maiz and he is working on a json serializer for mochikit,
to serialize forms. What I was talking about is a JSON serializer for
objects on the server. I thinki it will be something like
render_to_page() but using the simplejson instead of django templates.
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/26/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> On 1/25/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> >
> > On 1/25/06, Jason Davies <[EMAIL PROTECTED]> wrote:
> > > I think that's the best we've got. Is it worth creating a wiki page?
> >
> > Yeah, let's collect the design decisions
On 1/25/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 1/25/06, Jason Davies <[EMAIL PROTECTED]> wrote:
> > I think that's the best we've got. Is it worth creating a wiki page?
>
> Yeah, let's collect the design decisions and code examples on a wiki page.
I'm writing up a draft of this ri
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
Many thanks
--
petef
On Jan 26, 2006, at 9:04 AM, petef wrote:
That sounds like it could be very handy. Is there somewhere I can
check
to see when you check your stuff in? Are you likely to close any
tickets? Are the commits available via email or rss or anything?
There's a few places you can see that stuff: on
Hi Jacob, thanks for responding.
That sounds like it could be very handy. Is there somewhere I can check
to see when you check your stuff in? Are you likely to close any
tickets? Are the commits available via email or rss or anything?
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
On Jan 26, 2006, at 5:27 AM, Peter Ferne wrote:
I'm about to implement a RESTful API to some Django models and
wondering whether to try and build on any of the patches checked in
against any of the tickets marked as duplicates or subsets of #115. Or
wait? Or just code from scratch?
I can't help
On 26 Jan 2006, at 0:02, Jeremy Dunck wrote:
This makes me think the world needs a wiki whose wikitext syntax is
restructured text.
Anybody know of one?
Apparently you can use ReST with MoinMoin:
http://moinmoin.wikiwikiweb.de/HelpOnParsers/ReStructuredText
It’s not the native wikitext, bu
On 1/25/06, Max Battcher <[EMAIL PROTECTED]> wrote:
> I've seen a home-brew Zope-based one. It would be real quick to build
> one as a django app... In fact its own my personal project todo list.
> How soon do you want it? :-)
Mine, too, but you may get to it first. As Soon As Our Copious Fre
Hi all,
I'm about to implement a RESTful API to some Django models and
wondering whether to try and build on any of the patches checked in
against any of the tickets marked as duplicates or subsets of #115. Or
wait? Or just code from scratch?
I can't help noticing that on 11 Oct 2005 jacob said:
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
36 matches
Mail list logo
