I would like to openly thank Jefferson Quesado for sharing a link with the ideal logic, having just had to adapt to my development environment.
Really, DataBase Views
are common database tables, with their values generated dynamically during your query, function as select
And they don’t take up space in the database, even though they’re persistent. My low understanding of this hampered in the creative search for a solution.
The detail really came from the fact of being persistent, are then considered real tables of the database and so, can also be mapped.
I created a class in my _models.py with the exact name of my Oracle database View in question, following the standard scope of a class representing a relational object. I inherited it from models.Model
, I added its attributes with the exact names and properties of the view fields that I intended to map (if you have questions about which properties to assign, take a look at the SQL of your table and see the properties of the fields that it references, including a very important detail, the Primary/Foreign Keys for your view model are actually the Keys of the tables that your abstract view, even if it seems unnecessary, would like to leave this detail with its due prominence here, since in the view scope there are no references to primary keys/secondary, but make no mistake and attribute primary_key=True
fields. Otherwise Django will raise an unknown ID exception when making any QuerySet
and then nothing done. Haha).
Finally, the class Meta
within of the model class of your data base view. Referencing your view as a real table (after all it in the entrails is).
class Meta:
managed = False
db_table = 'nome_da_sua_view'
I recommend a visit to link left by Jefferson Quesado, worth checking out.
I saw something here about the class
Meta
: https://blog.rescale.com/using-database-views-in-django-orm/ I hope it will be useful =]– Jefferson Quesado
If you have problems with English, say that I try to translate the relevant points
– Jefferson Quesado