(sorry this email bounced yesterday)
OP: in a nutshell, unless you fully understand the risks, you should avoid doing this on a site which is in production. However, this would be a great opportunity to learn about this subject in a dev environment. After all, thats how i learnt (except i made the mistake of doing it in production and now i have to support and maintain that bad code for 5 years) lol
On 1 Jul 2011 11:53, "patrickf" <patrick.f.fitzgerald@googlemail.com> wrote:
> I agree with Andres; based on your description, you should be able to
> do this with no issues. We are using a legacy database system with 15
> years worth of company data - constantly updated by a legacy web based
> app (written in delphi) - and have adding new functionality via django
> (both reading and writing to the same db) for about 18 months now,
> with no issues.
>
> You must: Create a stage environment by taking duplicates of your
> live data and use it to test, test, and test. And test again. Examine
> the data record by record to ensure that what you THINK is happening
> actually IS happening. Make sure that your models match from one
> application to another.
>
> Also read up on how transactions work in your particular database
> system - and check out how django handles them (eg:
> https://docs.djangoproject.com/en/dev/topics/db/transactions/#controlling-transaction-management-in-views).
>
> Transactions are designed to avoid data corruption, not eliminate race
> conditions - and a race condition is just as likely to occur in the
> same app as different apps sharing the same DB - and it is your
> responsibility to avoid them (ie in your code, not django or the DBMS)
> but there are many examples on how to avoid them, such as:
> http://stackoverflow.com/questions/1030270/race-conditions-in-django
>
> (I know that some of the advice above may seem obvious, but in my
> experience it hasnt been to some...)
>
> Good luck - Patrick
>
> On Jun 30, 12:53 pm, andres.osin...@gmail.com wrote:
>> In theory, unless you've disabled transactions, the database should be able to manage all contention issues.
>> Enviado desde mi BlackBerry de Movistar (http://www.movistar.com.ar)
>>
>>
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: ALJ <astley.lejas...@gmail.com>
>>
>> Sender: django-users@googlegroups.com
>> Date: Thu, 30 Jun 2011 04:46:15
>> To: Django users<django-users@googlegroups.com>
>> Reply-To: django-users@googlegroups.com
>> Subject: More than one project using the same database
>>
>> I have an extranet type project that has been running for a year. It
>> only has a maximum user base of about 50 people of which probably only
>> a few are using it at any one time. The users can add, edit and delete
>> items within the application
>>
>> However, we need to expose the data in that extranet application to a
>> another group of users but through another domain. Anonymous users
>> will be able to register requests to be contacted, and another group
>> of known users will be able to log in with read only access to see
>> the status of those requests.
>>
>> My question is, what are the issues that I need to think about (are
>> race issues one?), is it possible to detect if these issues could
>> occur in my particular situation, and how do you mitigate against
>> these.
>>
>> ALJ
>>
>> --
>> You received this message because you are subscribed to the Google Groups "Django users" group.
>> 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 athttp://groups.google.com/group/django-users?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups "Django users" group.
> 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.
>
-- > I agree with Andres; based on your description, you should be able to
> do this with no issues. We are using a legacy database system with 15
> years worth of company data - constantly updated by a legacy web based
> app (written in delphi) - and have adding new functionality via django
> (both reading and writing to the same db) for about 18 months now,
> with no issues.
>
> You must: Create a stage environment by taking duplicates of your
> live data and use it to test, test, and test. And test again. Examine
> the data record by record to ensure that what you THINK is happening
> actually IS happening. Make sure that your models match from one
> application to another.
>
> Also read up on how transactions work in your particular database
> system - and check out how django handles them (eg:
> https://docs.djangoproject.com/en/dev/topics/db/transactions/#controlling-transaction-management-in-views).
>
> Transactions are designed to avoid data corruption, not eliminate race
> conditions - and a race condition is just as likely to occur in the
> same app as different apps sharing the same DB - and it is your
> responsibility to avoid them (ie in your code, not django or the DBMS)
> but there are many examples on how to avoid them, such as:
> http://stackoverflow.com/questions/1030270/race-conditions-in-django
>
> (I know that some of the advice above may seem obvious, but in my
> experience it hasnt been to some...)
>
> Good luck - Patrick
>
> On Jun 30, 12:53 pm, andres.osin...@gmail.com wrote:
>> In theory, unless you've disabled transactions, the database should be able to manage all contention issues.
>> Enviado desde mi BlackBerry de Movistar (http://www.movistar.com.ar)
>>
>>
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: ALJ <astley.lejas...@gmail.com>
>>
>> Sender: django-users@googlegroups.com
>> Date: Thu, 30 Jun 2011 04:46:15
>> To: Django users<django-users@googlegroups.com>
>> Reply-To: django-users@googlegroups.com
>> Subject: More than one project using the same database
>>
>> I have an extranet type project that has been running for a year. It
>> only has a maximum user base of about 50 people of which probably only
>> a few are using it at any one time. The users can add, edit and delete
>> items within the application
>>
>> However, we need to expose the data in that extranet application to a
>> another group of users but through another domain. Anonymous users
>> will be able to register requests to be contacted, and another group
>> of known users will be able to log in with read only access to see
>> the status of those requests.
>>
>> My question is, what are the issues that I need to think about (are
>> race issues one?), is it possible to detect if these issues could
>> occur in my particular situation, and how do you mitigate against
>> these.
>>
>> ALJ
>>
>> --
>> You received this message because you are subscribed to the Google Groups "Django users" group.
>> 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 athttp://groups.google.com/group/django-users?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups "Django users" group.
> 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.
>
You received this message because you are subscribed to the Google Groups "Django users" group.
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