ou'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
>>
&
oups.com
> Date: Thu, 30 Jun 2011 04:46:15
> To: Django users
> 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 peo
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
ers@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 d
kBerry 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: Django users
> Reply-To: django-users@googlegroups.com
> Subject: More than one project using the same da
5
To: Django users
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 ca
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 appli
12 matches
Mail list logo
