Hi Wanrong, It's hard to give predictions on open source projects, the last comment on #3163 is advising that he/she cannot write the tests for some reason. And without tests the ticket won't be checked-in.
You can always try to give a hand writting suchs tests. Once the ticket has everything it should it doesn't take too long to get checked-in unless: a) no committer sees it (unlikely), b) somebody has concerns about the ticket, unlikely as it's marked "Accepted". So, if you feel brave enought you can take a look at http://www.djangoproject.com/documentation/contributing/ and try to get the ticket's patches to good shape ;) Marc. El dom, 13-01-2008 a las 23:04 -0500, Wanrong Lin escribió: > > Hi, Marc, > > This is great news. I am glad I have not re-written all my models with > all those duplicated stuff (I am sure that wouldn't make me feel I am > following the "DRY" principle). > > Is it possible to give any prediction when this great stuff will be > checked in? Thanks a lot. > > Wanrong > > Marc Fargas wrote: > > Hi Wanrong, > > Maybe you could live with something like: > > > > class common(models.Model): > > ... > > Meta: > > create_db_schema = False > > > > class Model_B(models.Model): > > ... > > Meta: > > create_db_schema = True > > > > But for this, you'll need to wait for #3163 [1] to be checked-in (and > > it's still waitting for tests). > > > > Cheers, > > Marc > > > > 1: http://code.djangoproject.com/ticket/3163 > > > > El s�b, 12-01-2008 a las 14:15 -0500, Wanrong Lin escribi�: > > > >> Hi, > >> > >> I have just started playing with Django and found it a pleasure to set > >> up web site (even just a toy system so far) using the frame work. Thank > >> you very much! > >> > >> I have a data model case that I think probably is quite common to other > >> people too, and I did not find a way to do it with current Django, so I > >> wonder whether the developers can take a look of it. > >> > >> My situation is: > >> > >> I have quite a few data model classes that share some common fields, so > >> I have the following model code: > >> > >> -------------------- > >> class Common(models.Model): > >> # common fields > >> ...... > >> > >> class Model_A(Common): > >> # extra fields > >> ...... > >> > >> class Model_B(Common): > >> # extra fields > >> ...... > >> ------------------- > >> > >> That works, except that a database table will be created for "Common", > >> which will never be used by itself. > >> > >> So I will just keep "Common" table empty, not a big deal. But, to make > >> it more elegant (which I suspect a lot of Python programmers are > >> obsessed about), can we add some kind of mechanism to tell Django that > >> "Common" is an "abstract model" that is not intended to be used by > >> itself, so no table needs to be created? > >> > >> Thank you for giving it a thought. > >> > >> Best regards. > >> > >> Wanrong > >> > >> > >> > >> > >> > >> >> > >> > > > --~--~---------~--~----~------------~-------~--~----~ > You received this message because you are subscribed to the Google Groups > "Django developers" 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-developers?hl=en > -~----------~----~----~----~------~----~------~--~--- > -- http://www.marcfargas.com -- will be finished some day.
signature.asc
Description: Esta parte del mensaje está firmada digitalmente
