from django.db import models
class ModelManagerReadOnly(model.Manager):
def update(self, *args, **kwargs):
pass
class ModelReadOnly(models.Model):
objects = ModelManagerReadOnly() # The ReadOnly manager.
def save(self, *args, **kwargs):
pass
#raise NotImplemented
def delete(self, *args, **kwargs):
pass
class Meta:
managed = False
abstract = True
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'
updated code
On Monday, 29 October 2012 09:58:52 UTC+2, Gregg Branquinho wrote:
>
> 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 <http://www.freightman.com/Legal/EmailDisclaimer> | Quote
> Disclaimer <http://www.freightman.com//Legal/QuoteDisclaimer> | 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<http://www.freightman.com/Legal/TradingTerms>
--
Email Disclaimer <http://www.freightman.com/Legal/EmailDisclaimer> | Quote
Disclaimer <http://www.freightman.com//Legal/QuoteDisclaimer> | 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<http://www.freightman.com/Legal/TradingTerms>
--
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/-/mh0ntSK1xF8J.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
