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 30 Jun 2011 16:46, "Cal Leeming [Simplicity Media Ltd]" <cal.leeming@simplicitymedialtd.co.uk> wrote:
> On Thu, Jun 30, 2011 at 4:36 PM, Tom Evans <tevans.uk@googlemail.com> wrote:
>
>> On Thu, Jun 30, 2011 at 4:24 PM, Cal Leeming [Simplicity Media Ltd]
>> <cal.leeming@simplicitymedialtd.co.uk> wrote:
>> >
>> > I agree the principle is *almost* the same, but the risks are higher,
>> > because OP said that the two applications are not the same, and that the
>> > external app performs db writes, thus increasing the risk even further.
>> > Andres said, that because the database has transactions, then the OP
>> should
>> > be fine. This is a huge overstatement, and could have left OP under the
>> > impression that race conditions wouldn't happen. The reason I've jumped
>> on
>> > this pretty hard, is simply because of a lack of respect for
>> > handling/understanding race conditions by some developers, and because
>> > Andres answered an issue which he clearly did not understand
>> properly. (of
>> > which the OP accepted that answer as correct). Could have lead to the OP
>> > having a very bad day a few days/weeks/months later lol.
>> >
>>
>> The applications have different purposes, it doesn't mean the data
>> structures aren't the same. You keep banging on about race conditions,
>> but I see no races here - unless you do something 'racy', but you can
>> do that easily enough with a single website.
>>
>
> I agree that the same could happen with any other single website. This is
> more about making sure the OP realises that race conditions do (and will)
> happen, despite if transactions are enabled or not.
>
>
>>
>> I have a site that is in a similar situation to this. The frontend
>> website is served from two different DCs, with multi master
>> replication between the sites, with read mirrors in each DC. There is
>> then a backend website, which runs from one of the DCs, and connects
>> to one of the master/slave to do live analysis of data. This works
>> perfectly.
>>
>> OP: Keep your model definitions the same between the sites, and you
>> will have no issues whatsoever, 100% guaranteed*.
>>
>> Cheers
>>
>> Tom
>>
>> * This is not a guarantee ;)
>>
>
> lol ;p
>
>
>>
>> --
>> 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.
>>
>>
-- > On Thu, Jun 30, 2011 at 4:36 PM, Tom Evans <tevans.uk@googlemail.com> wrote:
>
>> On Thu, Jun 30, 2011 at 4:24 PM, Cal Leeming [Simplicity Media Ltd]
>> <cal.leeming@simplicitymedialtd.co.uk> wrote:
>> >
>> > I agree the principle is *almost* the same, but the risks are higher,
>> > because OP said that the two applications are not the same, and that the
>> > external app performs db writes, thus increasing the risk even further.
>> > Andres said, that because the database has transactions, then the OP
>> should
>> > be fine. This is a huge overstatement, and could have left OP under the
>> > impression that race conditions wouldn't happen. The reason I've jumped
>> on
>> > this pretty hard, is simply because of a lack of respect for
>> > handling/understanding race conditions by some developers, and because
>> > Andres answered an issue which he clearly did not understand
>> properly. (of
>> > which the OP accepted that answer as correct). Could have lead to the OP
>> > having a very bad day a few days/weeks/months later lol.
>> >
>>
>> The applications have different purposes, it doesn't mean the data
>> structures aren't the same. You keep banging on about race conditions,
>> but I see no races here - unless you do something 'racy', but you can
>> do that easily enough with a single website.
>>
>
> I agree that the same could happen with any other single website. This is
> more about making sure the OP realises that race conditions do (and will)
> happen, despite if transactions are enabled or not.
>
>
>>
>> I have a site that is in a similar situation to this. The frontend
>> website is served from two different DCs, with multi master
>> replication between the sites, with read mirrors in each DC. There is
>> then a backend website, which runs from one of the DCs, and connects
>> to one of the master/slave to do live analysis of data. This works
>> perfectly.
>>
>> OP: Keep your model definitions the same between the sites, and you
>> will have no issues whatsoever, 100% guaranteed*.
>>
>> Cheers
>>
>> Tom
>>
>> * This is not a guarantee ;)
>>
>
> lol ;p
>
>
>>
>> --
>> 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