Hi, I've seen something which is not very "concept proof"... at least in SQLLite ( hasn't been tested on PostgreSql or MySql )
>>> class A(Models.models): ... name = CharField(primaryKey=True) ... field_1 = CharField() ... >>> class B(A) ... field_2 = CharField ... Django will then build the folowwing tables : CREATE TABLE xxx_A ( name VARCHAR() UNIQUE, FIELD_1 VARCHAR() ) CREATE TABLE xxx_B ( name VARCHAR() UNIQUE, FIELD_1 VARCHAR(), FIELD_2 VARCHAR() ) ... This is not safe and doen't follow the heritage paradigm : we can have a record in xxx_A which has the same id as a record in xxx_B ... but represents different instance of object ( for ex. different FIELD_1) ... We think in case of heritage, it should be better to have : CREATE TABLE xxx_A ( name VARCHAR() UNIQUE, FIELD_1 VARCHAR() ) CREATE TABLE xxx_B ( xxx_A_name VARCHAR() CONTRAINT REFERENCE xxx_A.name, FIELD_2 VARCHAR() ) Is it a limitation of SQLLite ? If not, how can we implement this mapping ? thanks, sebastien. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~----------~----~----~----~------~----~------~--~---
