Malcolm Tredinnick wrote: > On Fri, 2007-07-13 at 21:31 -0500, Carl Karsten wrote: >> I am experimenting with subclassing a model. The parent class will be an >> abstract class that does not get 'managed' by django. Only the subclass >> will, >> and the table the subclass works with will have all the fields. >> >> syncdb was able to create the table I expected, the admin let me add and >> save >> it, but then when I went to view it, error: >> >> ProgrammingError at /admin/core/message/1/ >> (1146, "Table 'djangodb.msg_abmessage' doesn't exist") >> >> (full details below) >> >> So is this just a small bug in the Admin, or is this totally unsupported and >> I >> should give up now? > > Currently unsupported. Work in progress at the moment and will be > available before 1.0. >
I think what I am trying to do is getting tangled up in a big ball of problem, and what I am looking for might be a simple fix. (or even working except for a bug in the admin UI.) What follows is an attempt to isolate my problem from a bigger problem, which will also help with the bigger problem. I just read over http://code.djangoproject.com/wiki/ModelInheritance and http://groups.google.com/group/django-developers/browse_thread/thread/1bc01ee32cfb7374/84b64c625cd1b402?tvc=2&q=Model+Inheritance#84b64c625cd1b402 I see a design methodology problem: there are at least 3 problems (or features) trying to be addressed and I think they are separate enough problems to have separate solutions. I see more than one reasonable solution proposed. Each has something to offer the developer, not mutually exclusive, and can even work in conjunction. I think breaking ModelInheritance into well defined parts is important. looking at my problem: class abMessage(models.Model): to = models.ForeignKey(User, related_name = "messages_received") body = models.TextField() class message(msg.models.abMessage): status = models.CharField(maxlength=1) The problem/solution I am looking for: abstract base, concrete subclass, subclass is persisted in one table in the db. Yet this is the one case that was listed as "I am not implementing the "everything in one table" storage model." seems to me this should be one of the first things done, given how easy it is compared to the other solutions discussed. "(1) What notation to use to declare a class as abstract?" I think one of the problems trying to be solved here is: how do we keep django's syncdb, Admin UI and such from 'finding' such a class and trying to create a persistence for it. This problem may exist in non ModelInheritance situations too, making it part of the ModelInheritance problem may limit the usefulness of the solution. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
