On 7 heinä, 22:25, Andrei Antoukh <[email protected]> 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
--
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.
