Hi guys thanks for the help so Far, from what I understand this is what I have to do for models..
<code>
from django.db import models
class ModelReadOnly(models.Model):
def save(self, *args, **kwargs):
pass
#raise NotImplemented
class Meta:
managed = False
class AppLog(ModelReadOnly):
log_no = models.AutoField(db_column=u'LOG_NO') # Field name made lowercase.
module_id = models.CharField(max_length=25, db_column=u'MODULE_ID') # Field name made lowercase.
user_name = models.CharField(max_length=25, db_column=u'USER_NAME') # Field name made lowercase.
full_name = models.CharField(max_length=80, db_column=u'FULL_NAME') # Field name made lowercase.
description = models.CharField(max_length=3500, db_column=u'DESCRIPTION', blank=True) # Field name made lowercase.
date_time_stamp = models.DateTimeField(db_column=u'DATE_TIME_STAMP') # Field name made lowercase.
class Meta:
db_table = u'APP_LOG'
</code>
Thanks should take car of the db structure and the save, now I need to look at the model manager to circumvent the update.. ?
On Thursday, 25 October 2012 08:59:53 UTC+2, Russell Keith-Magee wrote:
On Thu, Oct 25, 2012 at 12:43 PM, Gregg Branquinho <gr...@freightman.com> wrote:Hi Russel,First off thank you for the suggestion, I am going to give it a whirl and see how it works out.. I have a couple of concerns about the pricing database it the* it is on mssql and the data is spread accross 3 database on the same server so the query would have to be cross database.. which also pose's a problem.Genuine cross-database queries are going to be a problem regardless -- Django doesn't handle foreign keys that cross database boundaries. However, if it's just a matter of having three different data stores, that's not a problem at all -- it just means you'll have multiple entries in your database configuration.* the db's have like 300 table each..There's a "yikes" factor here in terms of the number of tables you'll need to configure, but inspected will help you out here, and once that's done, you shouldn't have any problems in practice.Before you answer I wat thinking of accessing the database on the view *yuck* via pyodbc.after your answer I have a couple more questions ?Is is possible to override how a model is loaded from the database with raw sql and then overide the save and update methods to do nothing ? I have look at ovveriding __init__ but all recommendation are against it, but since I am not saving would it make any difference ?You can certainly override the save() method and make it a no-op; you don't need to touch __init__ at all to do this. Just make a subclass of django.db.models.Model that defines a no-op save() method, and make sure all your "views" extend this base class. Simliarly, you can override the model manager to provide a default query set that makes the update a no-op. As a third line of defence, you can write a database router that directs write queries to a no-op database, so if something does accidentally trigger a database write, it won't allow the update to occur.Yours,Russ Magee %-)
Email Disclaimer | Quote Disclaimer | All business is undertaken subject to our General Trading Conditions, a copy of which is available on request and on our website www.freightman.com --
You received this message because you are subscribed to the Google Groups "Django users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/67rouu4BWUUJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to django-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
No comments:
Post a Comment