On Dec 2, 2007 8:27 PM, Karen Tracey <[EMAIL PROTECTED]> wrote: > On 12/2/07, Vivek Khurana <[EMAIL PROTECTED]> wrote: > > > > > On Dec 2, 2007 12:27 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> > wrote: > > > > The reason for this kind of approach is that I should be able to > > > > upgrade the core without affecting the extensions created by > > > > developers. > > > > > > > > > > To my regret, Django model inheretance, is not yet working. > > > > > > More info here: > > > http://code.djangoproject.com/wiki/ModelInheritance > > > > > > We have also found this. Building quick sites is very easy with > > > Django. Building 'framework' to build > > > something is difficult. For example here, we are making a e-commerce > > > software framework based on Django. > > > > Well i did a test after this posting. I created a class called Box as > following > > > > class Box( models.Model): > > width = models.IntegerField() > > height = models.Integer(Filed() > > > > then inherited a class from box as fllowing > > > > class Box2(Box): > > color = modles.IntegerFiled() > > > > Now when i build this model into the db it created two tables Box and > > Box2. Where Box2 has all the fields of Box plus the color filed. So we > > can say Model inheritance is working and I am fine with it too. > > No, really, model inheritance is currently unsupported, meaning the result > of subclassing models like this is undefined, likely to break in unexpected > ways, subject to change without warning or migration path in the future, and > really something you do not want to do. Besides, as you see, it doesn't > currently do what you want anyway. > > > > But > > what I am looking is a mechanism so that when I make any changes to > > Box model those are reflected in Box2 also while the additional fields > > of box2 are untouched. > > Should i build a separate table for custom fields ? or is there any > > mechanism which I am overlooking. > > > You probably want to use the same approach as Alex and use OneToOne fields. >
hmm.. what i cant figure out, are the advantages of OneToOne relation, instead of having a custom table like box_cstm and creating an inner join between Box and Box_cstm table ? or may be a view instead of an inner join ? > > > > > > Every e-commerce store have its own set of attributes associated with > > > product. To make it possible, we have created > > > basic models (Product,Category) and related customProduct, > > > customCategory to them. This allows end users and > > > developers to extend models, without inheritance, and without touching > > > basic tables. All this is working via OneToOne > > > relationship, which is not yet fully supported in Django, so we > > > maintain 5 patches to Django source code only to make > > > our software working. > > > > > > > Are these patches available some where ? > > I'd hope the problems have been reported in trac with fixes available as > patches in tickets. But a query of non-closed tickets with OneToOne in the > summary and patches available brings up only four tickets: > > http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&summary=%7EOneToOne&has_patch=1&order=priority > > and of course I don't know if these actually overlap at all with the > problems/patches Alex is referring to. But looking in trac for > OneToOne-related tickets would be a good idea if you're going to use > OneToOne fields -- there aren't actually that many open tickets for them. > will look into the available patches. regards VK -- The hidden harmony is better than the obvious!! --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to [email protected] 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 -~----------~----~----~----~------~----~------~--~---
