(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
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
Hi all and thanks for the feedback.
I'll elaborate on my situation. The sites have different uses but they
use exactly the same models. Infact the second site has no model.py of
its own. The second site's views simply import the required models
from the first site and, where possible, uses the sam
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
On Thu, Jun 30, 2011 at 4:36 PM, Tom Evans wrote:
> On Thu, Jun 30, 2011 at 4:24 PM, Cal Leeming [Simplicity Media Ltd]
> 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
On Thu, Jun 30, 2011 at 4:24 PM, Cal Leeming [Simplicity Media Ltd]
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.
On Thu, Jun 30, 2011 at 4:13 PM, Tom Evans wrote:
> On Thu, Jun 30, 2011 at 4:03 PM, Cal Leeming [Simplicity Media Ltd]
> wrote:
> > The advice given to you by Andres is absolutely wrong.
> > By doing this, you are opening yourself up to all sorts of race
> conditions.
> > If you absolutely must
On Thu, Jun 30, 2011 at 4:03 PM, Cal Leeming [Simplicity Media Ltd]
wrote:
> The advice given to you by Andres is absolutely wrong.
> By doing this, you are opening yourself up to all sorts of race conditions.
> If you absolutely must allow this, you may want to consider implementing an
> object l
The advice given to you by Andres is absolutely wrong.
By doing this, you are opening yourself up to all sorts of race conditions.
If you absolutely must allow this, you may want to consider implementing an
object locking server (we have used memcache to do this before), but you'd
need to handle
Hi Andres, that's what I was hoping was the case. I just wasn't sure.
ALJ
On Jun 30, 1: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.movi
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
Sender: django-users@googlegroups.com
Date: Thu, 30 Jun 2011 04:46:15
To: Djang
11 matches
Mail list logo
