Re: model subclassing
Thanks looks very helpful. I will look over that when I get a free moment. On Apr 9, 10:39 am, Rajesh Dhawan <[EMAIL PROTECTED]> wrote: > Hi, > > On Apr 9, 12:30 am, Chris <[EMAIL PROTECTED]> wrote: > > > I am trying create a custom model field that will create 2 field > > instances, a CharField and a booleanField. I am using this with > > signals and dispatchers to insert data entered from this custom field > > into another model/table that contains a boolean and char field. my > > question is: how can I return 2 field objects in a single model > > subclass class. Seems like it would be similar to what occurs in > > datetimeField but not sure how to implement. so end result would look > > something like this: > > > > > > > Any pointers on how to do this? > > Download the PDF from here and look at the Custom Model Fields > slides:http://toys.jacobian.org/presentations/2007/oscon/tutorial/ > > -Rajesh D --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: model subclassing
Hi, On Apr 9, 12:30 am, Chris <[EMAIL PROTECTED]> wrote: > I am trying create a custom model field that will create 2 field > instances, a CharField and a booleanField. I am using this with > signals and dispatchers to insert data entered from this custom field > into another model/table that contains a boolean and char field. my > question is: how can I return 2 field objects in a single model > subclass class. Seems like it would be similar to what occurs in > datetimeField but not sure how to implement. so end result would look > something like this: > > Any pointers on how to do this? Download the PDF from here and look at the Custom Model Fields slides: http://toys.jacobian.org/presentations/2007/oscon/tutorial/ -Rajesh D --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
model subclassing
I am trying create a custom model field that will create 2 field instances, a CharField and a booleanField. I am using this with signals and dispatchers to insert data entered from this custom field into another model/table that contains a boolean and char field. my question is: how can I return 2 field objects in a single model subclass class. Seems like it would be similar to what occurs in datetimeField but not sure how to implement. so end result would look something like this: some_model(models.Model): fields = customFields() so that I don't have to do something like this in the model that I will be calling this from some_model(models.Model): field_1 = customField1() field_2 = customField2() Any pointers on how to do this? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: model subclassing
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=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 -~--~~~~--~~--~--~---
Re: model subclassing
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. Regards, Malcolm -- If Barbie is so popular, why do you have to buy her friends? http://www.pointy-stick.com/blog/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: model subclassing
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? Sorry, bad news, look for the word "subclassing" at http://code.djangoproject.com. /L --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
model subclassing
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?
carl K
# msg/model.py
from django.db import models
from django.contrib.auth.models import User
class abMessage(models.Model):
to = models.ForeignKey(User, related_name = "messages_received")
sender = models.ForeignKey(User, related_name = "messages_sent")
subject = models.CharField(maxlength=50)
sent = models.DateTimeField()
recieved = models.DateTimeField()
read = models.BooleanField()
message = models.TextField()
def __str__(self):
return self.subject
# core/models.py
import msg.models
class message(msg.models.abMessage):
status = models.CharField(maxlength=1)
class Admin:
pass
mysql> describe core_message;
+---+-+--+-+-++
| Field | Type| Null | Key | Default | Extra |
+---+-+--+-+-++
| id| int(11) | NO | PRI | NULL| auto_increment |
| to_id | int(11) | NO | MUL | ||
| sender_id | int(11) | NO | MUL | ||
| subject | varchar(50) | NO | | ||
| sent | datetime| NO | | ||
| recieved | datetime| NO | | ||
| read | tinyint(1) | NO | | ||
| message | longtext| NO | | ||
| status| varchar(1) | NO | | ||
+---+-+--+-+-++
9 rows in set (0.01 sec)
mysql> select * from core_message;
++---+---+-+-+-+--+---++
| id | to_id | sender_id | subject | sent| recieved
|
read | message | status |
++---+---+-+-+-+--+---++
| 1 | 1 | 137 | are | 2007-07-13 21:11:57 | 2007-07-13 21:11:58
|
1 | asdfasdf | a |
++---+---+-+-+-+--+---++
1 row in set (0.00 sec)
ProgrammingError at /admin/core/message/1/
(1146, "Table 'djangodb.msg_abmessage' doesn't exist")
Request Method: GET
Request URL:http://dell29:8000/admin/core/message/1/
Exception Type: ProgrammingError
Exception Value:(1146, "Table 'djangodb.msg_abmessage' doesn't exist")
Exception Location: /usr/lib/python2.5/site-packages/MySQLdb/connections.py
in
defaulterrorhandler, line 35
Python Executable: /usr/bin/python
Python Version: 2.5.1
Traceback (innermost last)
Switch to copy-and-paste view
* /usr/lib/python2.5/site-packages/django/core/handlers/base.py in
get_response
70. # Apply view middleware
71. for middleware_method in self._view_middleware:
72. response = middleware_method(request, callback, callback_args,
callback_kwargs)
73. if response:
74. return response
75.
76. try:
77. response = callback(request, *callback_args, **callback_kwargs) ...
78. except Exception, e:
79. # If the view raised an exception, run it through exception
80. # middleware, and if the exception middleware returns a
81. # response, use that. Otherwise, reraise the exception.
82. for middleware_method in self._exception_middleware:
83. response = middleware_method(request, e)
? Local vars
Variable Value
callback
callback_args
(u'core', u'message', u'1')
callback_kwargs
{}
debug
e
ProgrammingError(1146, "Table 'djangodb.msg_abmessage' doesn't exist")
exceptions
mail_admins
middleware_method
>
request
, POST:,
COOKIES:{'sessionid': '33017c5d30752deb58d94a20dbe9f1eb'},
META:{'CONTENT_LENGTH': '', 'CONTENT_TYPE': 'text/plain', 'DISPLAY':
'localhost:14.0', 'DJANGO_SETTINGS_MODULE': 'ridgemoor.settings',
'GATEWAY_INTERFACE': 'CGI/1.1', 'HISTCONTROL': 'ignoreboth', 'HOME':
'/home/carl', 'HTTP_ACCEPT':
Re: Model subclassing
On 5/15/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > On Mon, 2007-05-14 at 16:13 -0700, Joe wrote: > > I was wondering what the status of this is? I know that it broke a > > while back with the introduction of magic object removal, and has been > > in the pipeline since. I just tested it out on my recent SVN checkout, > > and it seemed to create the tables in the database in the way that one > > would expect. However I am scared to start using it in case something > > goes awry with the model managers or some other eventuality. > > Is it safe to use? > > It completely doesn't work. You will end with the wrong managers on the > sub-classed models. Please be patient a little longer and use one-to-one > relations in the interim. Are one-to-one's recommend again now? (last time I looked they were recommending foreignkeys with unique=True instead) ~ Anders > > Regards, > Malcolm > > > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Model subclassing
On Mon, 2007-05-14 at 16:13 -0700, Joe wrote: > I was wondering what the status of this is? I know that it broke a > while back with the introduction of magic object removal, and has been > in the pipeline since. I just tested it out on my recent SVN checkout, > and it seemed to create the tables in the database in the way that one > would expect. However I am scared to start using it in case something > goes awry with the model managers or some other eventuality. > Is it safe to use? It completely doesn't work. You will end with the wrong managers on the sub-classed models. Please be patient a little longer and use one-to-one relations in the interim. Regards, Malcolm --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Model subclassing
I was wondering what the status of this is? I know that it broke a while back with the introduction of magic object removal, and has been in the pipeline since. I just tested it out on my recent SVN checkout, and it seemed to create the tables in the database in the way that one would expect. However I am scared to start using it in case something goes awry with the model managers or some other eventuality. Is it safe to use? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Model Subclassing and some questions
Hello, I am defining a Product class that gets inherited by various products, so I am defining in it all the base attributes that exist on all child products. I want to know if its possible to forbid changing the actual "products" table unless you add one of the actual child products. Also, what's the best method to design the model to be more extendable? 'Cause I might have to add a new kind of product in the feature, and right now I'm defining all models in the products app. Maybe I shouldn't add the Product class in the Model schema, and just have each of the products inherit it? code snippet: from django.core import meta class Product(meta.Model): name = meta.CharField(maxlength=25) company = meta.ForeignKey(Company) value = meta.FloatField(max_digits=9, decimal_places=3) price = meta.FloatField(max_digits=9, decimal_places=3) class Tile(Product): #size = selection = meta.CharField(maxlength=25) image = meta.ImageField() quantity = meta.IntegerField() --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: [0.91] Model, subclassing, accessing superclass ?
Laurent RAHUEL wrote: > Ooops, > > It should be : > > class Derived(Parent): > > def _pre_save(self): > do_some_other_things_here > self.my_method() > > Indentation problem ;-) Thanks Laurent, but there was a typo in my original post !-) It should have been: class Parent(meta.Model): ... def my_method(self): do_some_thing_here class Derived(Parent): def my_method(self): do_some_other_things_here try: Parent.my_method() except NameError: try: parents.Parent.my_method() except NameError: print "this (hum) 'magic' mumbo-jumbo is a royal PITA and " " sucks big time" print "(too bad 0.92 is not released yet)" -- bruno desthuilliers développeur [EMAIL PROTECTED] http://www.modulix.com --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: [0.91] Model, subclassing, accessing superclass ?
Ooops, It should be : class Derived(Parent): def _pre_save(self): do_some_other_things_here self.my_method() Indentation problem ;-) Laurent Le Jeudi 9 Mars 2006 14:21, Laurent RAHUEL a écrit : > Le Jeudi 9 Mars 2006 12:58, bruno desthuilliers a écrit : > > Hi, > > > hello hello > > > > I must be a bit dumb, but I find myself a bit stucked with model > > subclassing. Here's the problem: how does one call on the superclass > > method when extending this method in the subclass ? ie: > > > > class Parent(meta.Model): > > > > def my_method(self): > > do_something_here > > > > > > class Derived(Parent): > > > > def _pre_save(self): > > do_some_other_things_here > > Parent.my_method(self) # raises NameError, "Parent" is not defined > > parents.Parent.my_method(self) # idem, "parents" is not defined > > I guess you should do > > class Derived(Parent): > > def _pre_save(self): > do_some_other_things_here > self.my_method() > > You just inherit fields and methods from Parent. Your object is not a child > of Parent but an "extension" of Parent. > > Regards, > > Laurent. > > > Is this a known issue, or I'm I missing something ? FWIW, the method I'm > > trying to extend is actually _pre_save() - but I don't think it has much > > to do with this problem.. > > > > NB : I've solved the problem at hand using a template method pattern as > > a workaround, but if the bug is - as often - between the chair and the > > keyboard, please let me know... > > > > TIA > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[0.91] Model, subclassing, accessing superclass ?
hello hello I must be a bit dumb, but I find myself a bit stucked with model subclassing. Here's the problem: how does one call on the superclass method when extending this method in the subclass ? ie: class Parent(meta.Model): def my_method(self): do_something_here class Derived(Parent): def _pre_save(self): do_some_other_things_here Parent.my_method(self) # raises NameError, "Parent" is not defined parents.Parent.my_method(self) # idem, "parents" is not defined Is this a known issue, or I'm I missing something ? FWIW, the method I'm trying to extend is actually _pre_save() - but I don't think it has much to do with this problem.. NB : I've solved the problem at hand using a template method pattern as a workaround, but if the bug is - as often - between the chair and the keyboard, please let me know... TIA -- bruno desthuilliers développeur [EMAIL PROTECTED] http://www.modulix.com --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
