2012/7/9 Anssi Kääriäinen <anssi.kaariai...@thl.fi> > On 7 heinä, 22:25, Andrei Antoukh <n...@niwi.be> wrote: > > Hello! > > > > I am writing about the issues: > https://code.djangoproject.com/ticket/13867https://code.djangoproject.com/ticket/18468 > > > > I am not the author of these issues, but I think this feature is > > interesting to have in the ORM. > > I agree that we should not do things just because we can make! > > > > In the source code often put comments to clarify things. These comments > for > > the same project > > developer or someone who looks at the source code are often useful to > know > > how > > something works or understand something that is not entirely clear. > > > > In SQL's absolutely the same case. Sometimes you need to make comments on > > both tables to clarify > > the purpose and functionality, and in columns. All assume that if you > want > > to understand something, > > look at the source code, but this may not always be so. > > > > Right now, the behavior to make comments can be emulated using sql > > fixtures. And it has these drawbacks: > > > > * Is not portable between different database backends, 3 files need to > > write redundant for this in mysql, > > postgresql and sqlite (sqlite does not natively support comments, but you > > can emulate sqlhttp://stackoverflow.com/questions/7426205/sqlitecomments > > -adding-comments-to-tables-and-columns ) > > > > * It is more tedious to write SQL statements and you end up not making > the > > comments. > > > > Is a low priority feature (obviously) but I think it's something that > could > > facilitate the ORM. > > > > My first proposal is: > > Comments to model tables (for mysql, postgresql and sqlite3) as the first > > patch. > > Without any kind of magic by django, a simple attribute "comment" on > object > > "Meta". > > > > My initial proposal for postgresql implementation: > https://github.com/niwibe/django/tree/issue_18468 > > I am not sure this is something we want to support. To me a generic > "get_post_sync_sql(connection)" is a better approach. In addition to > comments you could add indexes, constraints and so on in the hook. It > should be called even for non-managed tables. That way you could use > views using the hook. Trivial example: > > class UserPostCount(models.Model): > user = models.OneToOneKey(User, primary_key=True, > db_column="user_id", on_delete=models.DO_NOTHING, > related_name='post_count') > post_count = models.IntegerField() > > class Meta: > db_table = 'user_post_count_view' > managed = False > > def get_post_sync_sql(connection): > if connection.vendor != 'postgresql': > raise NotImplementedError > return [ > """ > CREATE OR REPLACE VIEW user_post_count_view AS ( > SELECT user.id AS user_id, count(*) AS post_count > FROM user > JOIN user_posts ON user.id = user_posts.user_id > );""", > """ > COMMENT ON VIEW user_post_count_view IS 'A trivial view returning > post count for users.'; > """] > > There could also be a get_post_flush_sql(connection) hook. > > It seems best if the hooks are called in a second pass - that is, the > whole schema is already installed into the DB before running any of > the post_sync SQL. > > Why not use the initial SQL files we already have? They are ran every > time after flush - which means they are useless for defining views for > example - and at least I like to keep the SQL together with model > definition. In addition (IIRC) there are some problems with backends > which do not support executing multiple statements in one go. Still, > one can do logic in the hook, while the initial SQL files are flat > files. > > - Anssi > > Hi Anssi!
I had submitted a proposal very simplistic. But your idea seems great! In fact I love it! And I would solve much more. As you've said: indexes, constrains, etc.. I will present a proposal for implementation with this in mind. Andrei Antoukh -- Andrei Antoukh - <n...@niwi.be> http://www.niwi.be/page/about/ http://www.kaleidos.net/A5 <http://www.kaleidos.net/A5694F/>-- 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. 694F/ <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.
