The thing is in my app, everything would be done on runtime. The idea is to
have a minimal app "base" and once you're on in, you'd have a list of
applications that you can install. So If I have "base" and "Employee", and
then I want to install "Fleet", only migrations from Fleet would have to be
It sounds to me like your data modelling is wrong. You can either have a
one-to-one table2 acts as an extension of table1, a view that combines
multiple tables into one "virtual table" or have one table and two models
that use the table. One, the superset, would be managed, the other would
only
Each model represents one table on the DB. Modifying it in two different
apps (hence creating two different sets of migrations) might result in
breaking changes. What if one migration affects something that is directly
referenced by the other app, but wasn't updated?
Also, what would the potential
I do not understand. Could you explain to me what it would break the
database and how ?
Le jeudi 30 janvier 2020 17:37:22 UTC+1, Abhijeet Viswa a écrit :
>
> I think this would needlessly complicate the entire migration process. Two
> different app migrations (and possibly even more) would have
I think this would needlessly complicate the entire migration process. Two
different app migrations (and possibly even more) would have be considered
and executed in sequence to prevent anything breaking on the database.
On Thu, 30 Jan 2020 at 22:00, LBris wrote:
> I've never said it isn't saved
I've never said it isn't saved in database. It is saved but in the table of
the employee since hrfleetemployee inherits from employee. It simply adds
this field to the table of Employee
Le jeu. 30 janv. 2020 à 5:24 PM, Abhijeet Viswa a
écrit :
> How would the fields in HRFleetEmployee be persist
How would the fields in HRFleetEmployee be persistent and linked to a
particular Employee or Vehicle without being saved in the database? Or did
I understand your code and request wrong?
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributio
No this is not a django-user-code related post. The code I provided was
only an example to illustrate the feature request.
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and
I think this is more of a django-users comment, so I'll post Adam's
template for places.
I think you've found the wrong mailing list for this post. This mailing
list is for the development of Django itself, not for support using Django.
This means the discussions of bugs and features in Django its
Hi everyone,
Would it be possible to provide a new inheritance mechanism between classes
in Django ?
I explain my point :
I have an app, for instance "HR": In this app, I would manage a model that
is called "Employee". I store several information on this model and it's
fine.
Suppose I have a
t it be great to be able to inherit django models like any other
> python class? I.e not like the default multi-table inheritance.
>
> "How would this differ from an abstract model" you may ask. Well, it is sort
> of like an abstract model inheritance, except for the abstrac
Hello!
Wouldn't it be great to be able to inherit django models like any other
python class? I.e not like the default multi-table inheritance.
"How would this differ from an abstract model" you may ask. Well, it is
sort of like an abstract model inheritance, except for the abstr
On 25 September 2012 17:45, Alex Ogier wrote:
> There's a big thing you cannot do without grouping models: you can't have
> an abstract base class relate to another abstract base class. Django's
> foreign key mechanism doesn't know how to relate to a to-be-instantiated
> concrete class.
>
Not en
On Mon, Sep 24, 2012 at 12:33 PM, Daniel Sokolowski <
daniel.sokolow...@klinsight.com> wrote:
> It also seems the current abstract model mechanism can do everything a
> model library can minus the model prefixing and the model grouping; that
> though I would just tackle using a naming convention
and as such can change - thank you
for considering it.
From: Jonathan Slenders
Sent: Monday, September 24, 2012 9:55 AM
To: django-developers@googlegroups.com
Subject: Model inheritance extended.
Hi everyone,
This may be interesting to some of you. I created a small library for
inheritance of
On Mon, Sep 24, 2012 at 9:55 AM, Jonathan Slenders
wrote:
> Hi everyone,
>
> This may be interesting to some of you. I created a small library for
> inheritance of a set of models.
> It's best to go quickly through the Readme on the site below.
>
> We felt a need for this, but I'm wondering whethe
> On 24 syys, 16:55, Jonathan Slenders
> wrote:
>> This may be interesting to some of you. I created a small library for
>> inheritance of *a set of* models.
>> It's best to go quickly through the Readme on the site below.
>>
>> We felt a need for this, but I'm wondering whether some kind of inhe
On 24 syys, 16:55, Jonathan Slenders
wrote:
> This may be interesting to some of you. I created a small library for
> inheritance of *a set of* models.
> It's best to go quickly through the Readme on the site below.
>
> We felt a need for this, but I'm wondering whether some kind of inheritance
>
Hi everyone,
This may be interesting to some of you. I created a small library for
inheritance of *a set of* models.
It's best to go quickly through the Readme on the site below.
We felt a need for this, but I'm wondering whether some kind of inheritance
like this has been discussed before. And
On Jun 4, 5:58 pm, Jeremy Dunck wrote:
> On Fri, Apr 20, 2012 at 9:01 AM, Anssi Kääriäinen
> > Could we force the caller to define the wanted signal inheritance mode
> > when .connect() is called? The inherit mode must be one of True,False
> > or None. Default of None means no inheritance (as now)
On Fri, Apr 20, 2012 at 9:01 AM, Anssi Kääriäinen
wrote:
> On Apr 12, 10:27 pm, Anssi Kääriäinen wrote:
>> > So perhaps we do need the signal inheritance behavior to be opt-in when
>> > connecting the signal handler. I think I'd like to see a deprecation
>> > path so that eventually the inheritan
On Apr 12, 10:27 pm, Anssi Kääriäinen wrote:
> > So perhaps we do need the signal inheritance behavior to be opt-in when
> > connecting the signal handler. I think I'd like to see a deprecation
> > path so that eventually the inheritance behavior is the default, and you
> > have to opt out of it,
On Apr 12, 9:58 pm, Carl Meyer wrote:
> So this is an argument against firing the init signals multiple times,
> for each superclass, but it's not an argument against changing the
> signal framework to include superclass receivers, as proposed in #9318;
> that would not change the performance char
I think changing when signals fire is bound to cause breakages for some
apps, and of the worst variety because signals both deal with basic data
integrity and are relatively opaque (I.e. debugging is a pain). Even if the
current behavior isn't what we would choose given a blank slate, it can't
real
On 04/12/2012 12:43 PM, Anssi Kääriäinen wrote:
> It is important that pre/post init signals will not get more expensive
> than they currently are. Even now they can give around 100% overhead
> to model.__init__(). And this is in a case where the currently
> initialized model has no signals attache
It is important that pre/post init signals will not get more expensive
than they currently are. Even now they can give around 100% overhead
to model.__init__(). And this is in a case where the currently
initialized model has no signals attached at all - it is enough that
_some_ model in the project
On Thu, Apr 12, 2012 at 12:19 PM, Carl Meyer wrote:
> Also, it isn't really true that the model signals are strictly tied to
> database activity; they are tied to events on Python model objects. One
> of the three signals under discussion is the pre/post_init signal, which
> fires anytime a model
On 04/12/2012 11:02 AM, Javier Guerra Giraldez wrote:
> IOW, i think the existing signals are database-related and should be
> fired only for the concrete part(s). if the abstract part wants to,
> it can send custom signals.
Also, it isn't really true that the model signals are strictly tied to
d
On 04/12/2012 11:02 AM, Javier Guerra Giraldez wrote:
> in my mental model, there are three types of inheritance:
>
> concrete: two tables, deletion should fire two signals, one for the
> child record and one for the parent record.
>
> abstract: there's no parent table, deletion should fire one s
On 04/12/2012 10:52 AM, Jeremy Dunck wrote:
> On Thu, Apr 12, 2012 at 9:31 AM, Carl Meyer wrote:
>> There's a discussion ongoing on ticket #18094
>> (https://code.djangoproject.com/ticket/18094) that has enough potential
>> back-compat implications that it seems worth getting feedback here.
>
> S
On Thu, Apr 12, 2012 at 11:31 AM, Carl Meyer wrote:
> Thoughts?
in my mental model, there are three types of inheritance:
concrete: two tables, deletion should fire two signals, one for the
child record and one for the parent record.
abstract: there's no parent table, deletion should fire one s
On Thu, Apr 12, 2012 at 9:31 AM, Carl Meyer wrote:
> Hi all,
>
> There's a discussion ongoing on ticket #18094
> (https://code.djangoproject.com/ticket/18094) that has enough potential
> back-compat implications that it seems worth getting feedback here.
Small note, I'll try to respond to the who
Hi all,
There's a discussion ongoing on ticket #18094
(https://code.djangoproject.com/ticket/18094) that has enough potential
back-compat implications that it seems worth getting feedback here.
Currently, when you delete a concrete-inheritance child model instance,
pre_delete and post_delete sign
Since multi-table-inheritance is the only kind of inheritance (apart
from abstract/proxy) supported by Django's ORM, I don't know what
other type of inheritance django_polymorphic would be referring to...
As per my original post, I want to store everything in one table (all
subclasses have t
Hi Carl,
> FWIW, django-model-utils [1] includes an InheritanceManager that
> implements polymorphic queries in a single query via select_related.
Ah, there goes my theory that I thought of it first :) And of course
introspection of subclasses via the reverse OneToOne descriptors is
perfect.
--
Hi Simon,
On Mar 4, 3:27 am, Simon Meers wrote:
> +1 for better polymorphic support in Django core; it is a very common
> problem which could do with an efficient and elegant solution.
> Regarding efficiency, if you can keep track of your subclasses
> effectively (potentially using a registry if
Hi Craig,
On Mar 4, 1:03 am, Craig de Stigter wrote:
> It looks like django_polymorphic does what I want. I'm not yet sure why it
> says it takes one query per type of model in a queryset. Unless it is
> talking about multi-table inheritance, in which each type would require a
> different join. B
On 4 March 2011 17:03, Craig de Stigter wrote:
> Hi guys
>
> Thanks for pointing those out. I knew I couldn't have been the first to want
> this. I guess I just didn't know the right words to search for here.
> It looks like django_polymorphic does what I want. I'm not yet sure why it
> says it ta
Hi guys
Thanks for pointing those out. I knew I couldn't have been the first to want
this. I guess I just didn't know the right words to search for here.
It looks like django_polymorphic does what I want. I'm not yet sure why it
says it takes one query per type of model in a queryset. Unless it
of the design options on the table at the time that model
inheritance was originally proposed. It was rejected at the time on
the grounds that it was too much overhead to impose on a general
inheritance solution (i.e., DB columns aren't free, and many
applications of inheritance don't requir
.3 ready, but doesn't anyone
> have thoughts on this? It's been two weeks ...
>
> Thanks
> Craig
>
> On Thursday, February 17, 2011 11:08:57 PM UTC+13, Craig de Stigter wrote:
>
> > Hi folks
>
> > Ever since Django started supporting various types of model
I realise everyone's been busy with getting 1.3 ready, but doesn't anyone
have thoughts on this? It's been two weeks ...
Thanks
Craig
On Thursday, February 17, 2011 11:08:57 PM UTC+13, Craig de Stigter wrote:
>
> Hi folks
>
> Ever since Django started suppor
Hi folks
Ever since Django started supporting various types of model inheritance I've
wondered why it lacks the kind that I would find most useful: python
behaviour differentiated based on the value of a field.
I'll explain with an example. Here's what I'd like to d
Hi,
This kind of question belongs to Django-Users group. Django-Developers
is for thread regarding the development of Django itself.
Thanks
On 18 sep, 04:51, nisha wrote:
> Hi,
>
> I have my models defined like this.
>
> class Image(models.Model):
> description = models.CharField(max_lengt
Hi,
I have my models defined like this.
class Image(models.Model):
description = models.CharField(max_length=500)
.
class ImageStatic(models.Model):
""" Image metadata not under change control
"""
def latest(self):
return self.image_s
Hi, first of all, this question maybe don't belongs here, i konw, but
anyway i didn't found noting about it in docs, and also in the source,
and 2 hours spend on it sisn't bring anything. So i had decided to ask
here
explanation, i have:
class A(models.Model):
name = models.CharFiled(, r
On Tue, 2009-01-27 at 06:12 -0800, PB wrote:
[...]
> But the motivation for a framework is to avoid rewriting code, and as
> a home for all the generic stuff no? :)
That's correct: no. :-)
It's not a home for *all* generic code, since that would lead to a five
million line framework. It's to pro
Malcolm, Tracy
Thankyou both for the feedback - it seems I'm coming from a very
common position, and I think it mainly stems from my misunderstanding
of the aims of the ORM, of which the tradeoffs you have helped
explain.
>Slight underestimation of the effort that went into the feature,
>there.
On Sun, 2009-01-25 at 09:51 -0800, PB wrote:
> Hi,
>
> I've been experimenting with model inheritance and have become pretty
> dissatisfied with the way it is implemented in Django. It seems that
> this part of the ORM has not received as much TLC and thought as the
>
Ah, thanks for the link - I'd done a little searching but I guess I
missed that one.
Karen Tracey wrote:
> On Sun, Jan 25, 2009 at 12:51 PM, PB wrote:
>
> >
> > Hi,
> >
> > I've been experimenting with model inheritance and have become pretty
> >
On Sun, Jan 25, 2009 at 12:51 PM, PB wrote:
>
> Hi,
>
> I've been experimenting with model inheritance and have become pretty
> dissatisfied with the way it is implemented in Django.
[snip gripes]
This general reaction has been registered before. You might want to search
Hi,
I've been experimenting with model inheritance and have become pretty
dissatisfied with the way it is implemented in Django. It seems that
this part of the ORM has not received as much TLC and thought as the
rest of the framework.
Some gripes:
- There is no way to find out wheth
Usage questions belong on django-users, not django-developers - this
list is for the discussion of the development of django itself.
--
Collin Grady
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developer
Can someone point to the correct way to do this?
Suppose i'm working in a tumblelog, it's basically , 4 o 5 tipes of
"post item" that share some cmmon information.
So the first approach i would go is:
cllass Post(models.Model):
here goes common metada of all things that can be "posted" like
On May 1, 2008, at 11:49 AM, [EMAIL PROTECTED] wrote:
>
>> Now that QSRF has landed, this type of thinking leads me to: who's
>> working on 121-rewrite?
>
> I'm fairly certain that in refactoring QuerySet, OneToOneField has
> been fixed. It's the base mechanism that allows multi-table
> subclas
> Now that QSRF has landed, this type of thinking leads me to: who's
> working on 121-rewrite?
I'm fairly certain that in refactoring QuerySet, OneToOneField has
been fixed. It's the base mechanism that allows multi-table
subclassing to work, in fact.
--~--~-~--~~~-
> Purely in terms of OO design, because it's cleaner. Object
> composition is usually a more appropriate paradigm than class
> inheritance. To take the example from the post that started this
> thread, the relationship between users and user profiles is "has-a",
> not "is-a". So what would be t
On Apr 25, 2008, at 3:40 PM, Marty Alchin wrote:
> *snip*
> class AuthorProfile(models.Model):
>user = models.OneToOneField(User)
>pen_name = models.CharField(max_length=255)
Now that QSRF has landed, this type of thinking leads me to: who's
working on 121-rewrite? And more important
Rajeev,
How, then, would you suggest handling multiple user groups? To
continue with a similar theme from above, let's say we had two user
groups, Authors and Publishers. When signing up, an Author might need
to input their first name, last name, email, and a password, but a
Publisher would onl
On Mon, Apr 28, 2008 at 3:59 AM, peschler <[EMAIL PROTECTED]> wrote:
>
> On 25 Apr., 21:40, "Marty Alchin" <[EMAIL PROTECTED]> wrote:
> >
> > Not to get too much into this discussion, but I tend to be slow to
> > understand design patterns and other paradigms. What then would be the
> > appro
I just started learning about extending Django's User model, so bear
with me as I make sure I understand these things correctly. So we can
subclass the User class doing something like:
class Reader(User):
fields...
class Author(User):
fields...
Does this mean that any new instance of Reade
On 25 Apr., 21:40, "Marty Alchin" <[EMAIL PROTECTED]> wrote:
>
> Not to get too much into this discussion, but I tend to be slow to
> understand design patterns and other paradigms. What then would be the
> appropriate way to handle an app that managed authors? I can see two
> possibilities:
>
> c
On Fri, Apr 25, 2008 at 3:26 PM, Ian Kelly <[EMAIL PROTECTED]> wrote:
> Purely in terms of OO design, because it's cleaner. Object
> composition is usually a more appropriate paradigm than class
> inheritance. To take the example from the post that started this
> thread, the relationship bet
On Fri, Apr 25, 2008 at 1:06 PM, AmanKow <[EMAIL PROTECTED]> wrote:
>
> Hmmm... I read the subclassing post. As a non-abstract child is
> essentially a one to one with some syntactical sweetness, I'm still
> not sure how using a one to one field is better suited than
> inheritance for extendi
Hmmm... I read the subclassing post. As a non-abstract child is
essentially a one to one with some syntactical sweetness, I'm still
not sure how using a one to one field is better suited than
inheritance for extending user.
Rajeev J Sebastion wrote:
> Because every app has its own concept/method
The multi-table inheritance stuff in queryset-refactor does
essentially what is mentioned in that article, except it merges the
namespace so that it's easier to use. That being said, it seems that
OneToOneField has been improved as well, for those who want to be
explicit about that link.
On Apr
On Fri, Apr 25, 2008 at 10:23 AM, AmanKow <[EMAIL PROTECTED]> wrote:
> Could you elaborate or point to elaboration on why non-abstract
> inheritance is a bad fit for extending user?
http://www.b-list.org/weblog/2007/feb/20/about-model-subclassing/
--
"Bureaucrat Conrad, you are technically c
On Fri, Apr 25, 2008 at 8:53 PM, AmanKow <[EMAIL PROTECTED]> wrote:
>
> > Well, I personally have been saying for over a year that inheritance
> > has never been and never will be the right way to do that, so I think
> > y'all know what my answer is...
>
> Could you elaborate or point to elabo
> Well, I personally have been saying for over a year that inheritance
> has never been and never will be the right way to do that, so I think
> y'all know what my answer is...
Could you elaborate or point to elaboration on why non-abstract
inheritance is a bad fit for extending user?
Thanks!
--~
On Wed, Apr 23, 2008 at 11:16 PM, Rob Hudson <[EMAIL PROTECTED]> wrote:
> Now that queryset-refactor has implemented model inheritance (and will
> soon be in trunk), will the recommended way to tie in new columns to
> contrib.auth.models.User change? For example, if we
I don't know if this should go to devs or users but I wanted to ask...
Now that queryset-refactor has implemented model inheritance (and will
soon be in trunk), will the recommended way to tie in new columns to
contrib.auth.models.User change? For example, if we want to add in
pr
On Tue, Apr 1, 2008 at 7:39 AM, Tim Chase
<[EMAIL PROTECTED]> wrote:
> If this is a fluke that will eventually be "fixed", will there be
> a way to replicate this sort of behavior (or at least some of the
> side-effects), to get/keep "mix-ins", such as
[...]
Yes. In fact, it already is fixed.
d, x, y, z)
>>
>> All I need to know is if this is some kind of fall-back till full-
>> blown model inheritance is implemented, or if this is just a fluke.
>
> It's a fluke. More information can be obtained from a Google search
> for "Django model inheritance&qu
Model inheritance is not there yet. You can take a look at the
queryset-refactor branch, since Changeset 7126 moder inheritance begun
to take shape.
The changeset also includes documentation about that. You can either use
this branch or wait until it gets merger to trunk.
http
On Tue, Apr 1, 2008 at 2:31 AM, jurian <[EMAIL PROTECTED]> wrote:
> All I need to know is if this is some kind of fall-back till full-
> blown model inheritance is implemented, or if this is just a fluke.
It's a fluke. More information can be obtained from a Google search
I think I might have the wrong idea about model inheritance.
I was using the 'newforms-admin' branch and implemented some model
inheritance just to see if it works and it did. Well, let's say that
it did what I had expected, or wanted it to do at the time.
class X(mo
I started playing with subclassing the auth models today. What's nice is
that when you subclass User with, say, UserProfile, all users get a
.userprofile property, so the functionality of get_profile() is there for
free with the bonus of multiple User subclasses if that's needed.
I was thinking it
_object = models.ForeignKey(ContentType)
>
> The just introduced model inheritance will even let me include fields
> common to ContentType descendant. I was just curios if,
>
> I understand this correctly and,
>
> which will be the preferred way.
Not at all. Models with abstract=T
On Feb 18, 2008 5:06 AM, Jiri Barton <[EMAIL PROTECTED]> wrote:
> The infamous commit #7126 seems to obsolete generic relations -- to
> me.
Not by a long shot.
To take your example, you'd need to go back and rewrite every single
model you'd like to use tags with to inherit from the appropriate b
The infamous commit #7126 seems to obsolete generic relations -- to
me.
class ContentType(models.Model):
class Meta:
abstract = True
class TaggedItem(models.Model):
content_object = models.ForeignKey(ContentType)
The just introduced model inheritance will even let me include
I'll be there, and I just noticed that I have a good use case for
model inheritance so I'll try to help out with this.
On Jan 25, 11:59 pm, David Cramer <[EMAIL PROTECTED]> wrote:
> I plan to attend, and I may be able to stay for the sprints this year.
> Model inheritan
I plan to attend, and I may be able to stay for the sprints this year.
Model inheritance is much on my wants list as well.
On Jan 25, 4:04 pm, "Tom Tobin" <[EMAIL PROTECTED]> wrote:
> Over at The Onion, we're working on a major new project in Django.
> (By "majo
ason I was
hired. ^_^ Just like everyone, though, we have a list of stuff we'd
like to improve; at the top of that list is model inheritance.
So, we'd like to put our swag, and our keyboards, where our collective
mouth is. (Or something like that.)
We're planning on attending Py
On Dec 30 2007, 12:47 am, "Waylan Limberg" <[EMAIL PROTECTED]> wrote:
> On Dec 29, 2007 8:49 AM, Sridhar Ratnakumar <[EMAIL PROTECTED]> wrote:
>
> > [that link is going down -- hence, I'm pasting the contents below]
>
> Your willingness to share is much apprciated. However, things tend to
> beco
On Dec 29, 2007 8:49 AM, Sridhar Ratnakumar <[EMAIL PROTECTED]> wrote:
>
> [that link is going down -- hence, I'm pasting the contents below]
>
Your willingness to share is much apprciated. However, things tend to
become quickly forgoten and lost in the list. Not that we do so on
pupose; that's j
[that link is going down -- hence, I'm pasting the contents below]
Django ORM does not support inheritance. Inheritance is a good thing.
Often I want some of the database models to share some common fields
and the same manager. For example consider the case of adding the
delete proxy.
class Reta
1. You still can use super in NonDeleted.get_query_set by using
self.__class__ instead of NonDeleted
2. It could be better to use issubclass(key, models.Manager) instead
of key == 'objects'
On 19 дек, 11:53, Sridhar Ratnakumar <[EMAIL PROTECTED]> wrote:
> I wanted to share this little hack of min
I wanted to share this little hack of mine - conceptual (not database-
based) inheritance for django:
http://nearfar.org/blog/django-model-inheritance.html
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django deve
Erm,
I've just refreshed my django install to rev 3954 (per object
permissions branch) and deiscovered that model inheritance seems to
work...
Is this right? Have you guys secretly injected model inheritance back
into the distro? Or is the per-object-permissions branch running from
a
gress been made, if not, why?
>
> Can I help? As far as I can see developers need to agree whether to use
> vertical, horizontal or filtered ORM mapping and Just Implement It.
This is blocking on me at the moment. The query rewrite stuff needs to
be finished first, then model inheritance
Hello,
I would really like to use inheritance in my models. In 0.95 this
doesn't work. According to
http://code.djangoproject.com/wiki/ModelInheritance there is some work
underway in supporting it. Has some progress been made, if not, why?
Can I help? As far as I can see developers need to agree
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
1 - 100 of 131 matches
Mail list logo
