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.leem...@simplicitymedialtd.co.uk> wrote: > On Thu, Jun 30, 2011 at 4:36 PM, Tom Evans <tevans...@googlemail.com> wrote: > >> On Thu, Jun 30, 2011 at 4:24 PM, Cal Leeming [Simplicity Media Ltd] >> <cal.leem...@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+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
