I’m playing around today with Django and Oracle, connecting my application to data from another application.<\/p>\n
First thing I realized is that I cannot use a table or view that does not have a single column primary key. \u00c2\u00a0Without a primary key, the Django Admin system complains loudly. \u00c2\u00a0For those that do have a good key, it’s pretty easy to declare it to Django:<\/p>\n
id_number = models.CharField(max_length=10,primary_key=True)<\/pre>\nThis will override Django’s default behavior of using ‘ID’ as the primary key field name.<\/p>\n
Next, there’s a specific way that one declares the schema and table\/view name for the existing structure. \u00c2\u00a0Each has to be in quotes, with the entire name also in quotes. \u00c2\u00a0Something like this:<\/p>\n
class Meta:\r\n db_table = u'\"SCHEMA\".\"TABLE\"'<\/pre>\nSomething else that I needed to do was to not allow changes to the external data. \u00c2\u00a0This is enforced by Oracle security, but I also wanted to make it clear in my code that saves and deletes are not going to happen. \u00c2\u00a0To do this, I create an abstract class upon which my other models are based, which includes the redefined save() and delete() methods that raise a NotImplemeted error. \u00c2\u00a0These produce a nice, big error page when DEBUG=TRUE.<\/p>\n
class AdvanceBase(models.Model):\r\n \"\"\"\r\n Abstract base class for accessing tables and views in the external schema\r\n \"\"\"\r\n\r\n class Meta:\r\n abstract = True\r\n\r\n def save(self): # No saving allowed\r\n raise NotImplementedError\r\n\r\n def delete(self): # No deletes allowed\r\n raise NotImplementedError<\/pre>\nI decided to try setting up a relationship between two of the external tables. \u00c2\u00a0This wasn’t really different than any other foreign key, with one exception. \u00c2\u00a0I wanted to rename the field to follow Django conventions. \u00c2\u00a0Orginally called SCHOOL_CODE, I changed it to SCHOOL – same as the foreign key object. \u00c2\u00a0In order to still map to the correct DB column, the db_column attribute is used to declare the original name:<\/p>\n
school = models.ForeignKey(School,blank=True,null=True,db_column='SCHOOL_CODE')<\/pre>\nOne more experiment – using a manager. \u00c2\u00a0In this case I wanted to filter a table to include only living people. \u00c2\u00a0 The fact that I was using an external table did not change the method for this:<\/p>\n
class PersonManager(models.Manager):\r\n def get_query_set(self):\r\n return super(PersonManager, self).get_query_set().filter(status='A')<\/pre>\nSomething else I learned was that the Django Admin will use the first manager listed for a model. \u00c2\u00a0By placing the reference to the PersonManager ahead of the normal objects, the Admin only showed living people.<\/p>\n
I’m sure there will be more later as I dig deeper into using external data. \u00c2\u00a0I have an actual application related goal driving my interest, so I should get this solved soon.<\/p>\n
As always, leave your comments below.<\/p>\n","protected":false},"excerpt":{"rendered":"
I’m playing around today with Django and Oracle, connecting my application to data from another application. First thing I realized is that I cannot use a table or view that does not have a single column primary key. \u00c2\u00a0Without a primary key, the Django Admin system complains loudly. \u00c2\u00a0For those that do have a good … <\/p>\n