2012/7/24 Anssi Kääriäinen <anssi.kaariai...@thl.fi> > On 22 heinä, 23:01, Andrei Antoukh <n...@niwi.be> wrote: > > Hello! >
Hello! > > > > I started working on what had been proposed. In the commithttps:// > github.com/niwibe/django/commit/af887029integeintege614ca53d8...< > https://github.com/niwibe/django/commit/af887029614ca53d8bdab23f0a40e...> > > is > > the initial implementation. It is based on the Anssi idea. > > > > I have some doubts about how to make things better. The proposed method > > should return a list of sql statements: > > ["COMMENT ON TABLE fooapp_sampletable IS 'Foo comment';"] > > > > or a list of tuples with sql statements with possible arguments: > > > > [("COMMENT ON TABLE fooapp_sampletable IS %s", ["Foo comment"])] > > > > Currently, the initial implementation, is a list of tuples, but I'm > > wondering if the best option. I think that this is not usabe for commands > > such as sqlall because the returned sql is not complete, if only partial, > > failing to place them arguments. > > I do think the sqlall output should be usable as is. That is, the > return value should be list of strings. This might mean that one has > to create the SQL in a way that is susceptible to SQL injection > attacks, but I don't see that as a problem. The post_sync method's SQL > can't be ran or controlled by users, so there is no attack vector. > OK! > > I have a couple of questions: > 1) How does this work in model inheritance situations? If the base > model defines post_sync_sql(), wouldn't that be called again for the > child models? Maybe it is possible to run the method only if it is > defined in the current class directly. This should be possible by > inspecting the model's __dict__ for the method instead of using > hasattr. > Good observation! > 2) What is the order in which the post_sync_sql methods are called? > This could be important for some use cases (one view depends on > another view for example). I guess the order is app for app in > INSTALLED_APPS, models in the order they are found from app's > models.py? The order should be tested and documented. > I'll think about it. Currently uses the same order as syncdb, even if not the most appropriate for this. We could think of a way to define the order of execution by the user. I created the asociated ticket for this feature: https://code.djangoproject.com/tidcket/18672<https://code.djangoproject.com/ticket/18672> Andrey. > > - Anssi > > -- > 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 > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- Andrei Antoukh - <n...@niwi.be> http://www.niwi.be/page/about/ http://www.kaleidos.net/A5694F/ "Linux is for people who hate Windows, BSD is for people who love UNIX" "Social Engineer -> Because there is no patch for human stupidity" -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
