On 26 heinä, 18:55, Andrei Antoukh <[email protected]> wrote: > 2012/7/24 Anssi Kääriäinen <[email protected]> > > > On 22 heinä, 23:01, Andrei Antoukh <[email protected]> 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.
Before proceeding too far in the morel pre/post sync hooks, lets see if the other current thread about a similar issues yields a better API. The other thread is about raw SQL on pre/post sync, and while it isn't dealing with the exact same issue as this thread, there is a lot of overlap. See http://groups.google.com/group/django-developers/browse_thread/thread/c4dd1a333ae60356 - Anssi -- 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.
