Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Refs #6148 -- Meta table api #6162
Add Model._meta.table_cls attribute to represent table-like objects. Add schema qualified table support.
Continuation from #5278.
Not going to be implemented in this PR:
Test project for PostgreSQL here:
The feature allows for using schema qualified table names. There is no migrations support for this yet, though. With migrations support #6148 would be fixed. Another compelling (but untested) use case is view-like features. That is, you could have models that query from a subquery. The essence is the ability to plug in raw SQL in to normal ORM queries. Something like: class Book(models.Model): title = models.TextField() class Author(models.Model): age = models.IntegerField() book = models.ManyToManyField(Book) class AverageAuthorAge(models.Model): book = models.OneToOneField(Book, primary_key=True) average_author_age = models.DecimalField() class Meta: table_cls = View( 'select avg(age) as average_author_age, book_authors.book_id ' ' from author inner join book_authors on ' ' author.id = book_authors.author_id ' ' group by book_id') Currently, if using a table_cls in model.Meta, the behavior of migrations framework is undefined.
I recall an idea brought up for the problem that Oracle and MySQL schema conflicts between production and testing. The idea was something like database setting 'test_schema_mapping'. This maps production schema name to testing schema name. If you use identity mapping, then testing and production uses same schema names. In that case the user is responsible for any problems that might cause.
I'm not going to implement that for the initial merge to Django unless requested. I'd like to keep this patch as simple as possible as I don't have too much time. This means the initial merge will have only PostgreSQL support.