On 8/4/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> Next time I'm picking two Place types that have absolutely nothing in
> common so that you can't twist my examples into cases like this.
> Restaurants and SmallCometsInTheOortCloud, for example. I'm making this
> too easy for you.
Here's
On 8/8/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> On Tue, 2006-08-08 at 07:35 +0800, Russell Keith-Magee wrote:
> [...]
> >
> > For those late to the discussion, it should be noted that this was one
> > of the ideas proposed for implementing inheritance. It was rejected on
> > two groun
Alan Green wrote:
> Sure. In this case you would need a discriminator attribute on Place.
[...]
> I'd be pleased to see Django require discriminator attributes on
> superclasses, and then automagically retrieve the correct subclasses
> at the correct times. It seems to work well enough in ORMs suc
On Tue, 2006-08-08 at 10:39 +1000, Malcolm Tredinnick wrote:
[...]
> This stuff is hard not because we are not very clever, but because it is
> quite possibly fundamentally hard. There is a famous comment from Bjarne
> Stroustrup where he mentioned that AT&T (his employer) had tried very
> hard to
On Mon, 2006-08-07 at 09:26 -0700, Bjørn Stabell wrote:
> Okay, I've got one more question. If we're not going to support
> querying for an object's real type, it becomes quite cumbersome to do
> anything polymorphically, which kind-of is the point of
> object-orientation.
This stuff is hard not
On Tue, 2006-08-08 at 07:35 +0800, Russell Keith-Magee wrote:
[...]
>
> For those late to the discussion, it should be noted that this was one
> of the ideas proposed for implementing inheritance. It was rejected on
> two grounds:
>
> 1) Lack of support for legacy databases
> 2) The number of jo
On 8/8/06, Alan Green <[EMAIL PROTECTED]> wrote:
Hi Bjørn,Sure. In this case you would need a discriminator attribute on Place.I'm thinking of code along the lines of:class Place(models.Model):...discriminator = models.CharField(maxlength=50)
def save(self):self.discriminator =
Hi Bjørn,
Sure. In this case you would need a discriminator attribute on Place.
I'm thinking of code along the lines of:
class Place(models.Model):
...
discriminator = models.CharField(maxlength=50)
def save(self):
self.discriminator = self.__class__.__name__.lower()
Okay, I've got one more question. If we're not going to support
querying for an object's real type, it becomes quite cumbersome to do
anything polymorphically, which kind-of is the point of
object-orientation.
For example, to use the same URI spec & view for all the subtypes.
OPTION 1: lots of
Joseph & Malcom, thanks for the comments. Just wanted to make sure I
could stand my ground in the face of Rails-istas :)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this gr
On Fri, 2006-08-04 at 10:28 -0600, Joseph Kocherhans wrote:
> On 8/4/06, Bjørn Stabell <[EMAIL PROTECTED]> wrote:
> >
> > Just a question; how does this compare pros and cons with single-table
> > inheritance, used in Rails? See:
> >
> > http://twelvelabs.com/singletable/index.html
You probabl
On 8/4/06, Bjørn Stabell <[EMAIL PROTECTED]> wrote:
>
> Just a question; how does this compare pros and cons with single-table
> inheritance, used in Rails? See:
>
> http://twelvelabs.com/singletable/index.html
http://www.objectmatter.com/vbsf/docs/maptool/ormapping.html
Check out the section
Just a question; how does this compare pros and cons with single-table
inheritance, used in Rails? See:
http://twelvelabs.com/singletable/index.html
Rgds,
Bjorn
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"
On 8/4/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
On Fri, 2006-08-04 at 13:36 +0800, Russell Keith-Magee wrote:> Place.objects.filter(restaurant__chef_name='Bork')>> Any comments?I hate it (sorry).Apologies - I wasn't actually suggesting it or requesting it. I dislike it too; It just occurre
On Fri, 2006-08-04 at 13:36 +0800, Russell Keith-Magee wrote:
>
> On 8/4/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
[...]
> Related note that just occured to me: is there any intention to extend
> query terms with this attribute-based inheritance syntax? i.e., is
> something like:
>
>
On 8/4/06, Malcolm Tredinnick <[EMAIL PROTECTED]
> wrote:
> Obviously, I'd still prefer an _actual_ duck, but this seems a> reasonable alternative in an duckless world.I could subclass everything from Duck if you like. Poor man's ducktyping. :-)
Hey! Great idea! +1 :-) I haven't worked out the API
This is why posting this stuff pays off. Somebody comes back with a
cluestick in hand and helps out. :-)
On Thu, 2006-08-03 at 21:01 +0800, Russell Keith-Magee wrote:
>
> On 8/3/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
[...]
>
> (2) If a class has derived classes, you can acces
On 8/3/06, Malcolm Tredinnick <[EMAIL PROTECTED]
> wrote:Sorry to see duck typing go, but I can see that the problems you mentioned could open up a real nest of vipers (especially debugging the spider-web of queries). Oh well... it was nice while it lasted :-)
So, new, improved inheritance API (ac
Clearing out my list of TODOs after OSCON...
Jacob, Adrian and I had a discussion about model inheritance last week,
trying to nail down some of the features. This resulted in a few changes
to the earlier proposal in
http://groups.google.com/group/django-developers/browse_frm/thread/1bc01ee32cfb7
19 matches
Mail list logo
