Yes, true, its a matter of trade offs. With a verison you add
irrelavant data to your table schema. But potentially gain some
performance. I tend to like my tables clean and relevant. Just a
personal preference.
Plus it means the locking can work regardless of the table schema.
Once you have to
blems with CLOB / BLOB fields).
Regards,
--Tim
-Original Message-
From: django-users@googlegroups.com
[mailto:[EMAIL PROTECTED] On Behalf Of ChaosKCW
Sent: zaterdag 4 maart 2006 23:57
To: Django users
Subject: Re: Django in a Load-Balanced environment (ORM issues) ...
[...]
Another a
>They way I would enivsage adding this functionality to Django would be
>that in your model you specify, for each Model object (=table), that it
>is to be versioned. Versioning would automatically add a '_version'
>column to the generated DDL, and the standard Django save() routines
>would take ca
On 2/28/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
Alternatively, SQLAlchemy solves this problem by implementing anidentity map, which is quite cool. You should be able to useSQLAlchemy with the rest of Django with no problems at all -- the onlything you won't be able to take advantage of is th
>They way I would enivsage adding this functionality to Django would be
>that in your model you specify, for each Model object (=table), that it
>is to be versioned. Versioning would automatically add a '_version'
>column to the generated DDL, and the standard Django save() routines
>would take ca
That sounds like a great suggestion Tim. That's the way I would expect
it to work as well.
--~--~-~--~~~---~--~~
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@goog
ango users
Subject: Re: Django in a Load-Balanced environment (ORM issues) ...
I just want to echo Peter and Ivan's sentiments on NOT making this
default behavior. What attracted me to Django was a simple, fast,
elegant framework for quickly building common types of web
applications. I've
On 3/1/06, DavidA <[EMAIL PROTECTED]> wrote:
> I just want to echo Peter and Ivan's sentiments on NOT making this
> default behavior.
Thanks for the feedback (to all of you)! Rest assured this will not be
made default behavior. Generally our philosophy in building Django is
to activate potentiall
I just want to echo Peter and Ivan's sentiments on NOT making this
default behavior. What attracted me to Django was a simple, fast,
elegant framework for quickly building common types of web
applications. I've wandered into the tarpits of J2EE in my past life
and I was looking for something at th
Peter Harkins wrote:
>I can see why folks would want this, but I'd like to toss in a vote
>against it being on by default.
>
I just started to write the same thing :-)
> It strikes me as spooky action at a
>distance -- because another process possibly on another machine saved
>the state of one o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Feb 28, 2006 at 02:36:41PM -0600, Adrian Holovaty wrote:
> With that said, I think it would be a fantastic improvement to
> Django's database layer. You could solve it in the interim by creating
> a "status" field on your model, override save(
Hey guys ... that's fantastic ... just the sort of response I was
hoping to see from the start of this conversation. Like they say in AA
"the first step is admitting you have a problem" ;-)
I will definitely explore all those options and make my contributions
to the project.
All the best,
Zeb
On 2/28/06, ZebZiggle <[EMAIL PROTECTED]> wrote:
> I agree that this problem is pretty fundamental. I don't know what
> worries me more, the fact that the problem exists or the architects
> don't see the problem.
>
> I think in my case I can isolate the offending code and use some form
> of "doubl
On 2/28/06, ZebZiggle <[EMAIL PROTECTED]> wrote:
> I agree that this problem is pretty fundamental. I don't know what
> worries me more, the fact that the problem exists or the architects
> don't see the problem.
I wouldn't put it that. It is a problem and things like transaction
support do show
Thx for the feedback guys.
I agree that this problem is pretty fundamental. I don't know what
worries me more, the fact that the problem exists or the architects
don't see the problem.
I think in my case I can isolate the offending code and use some form
of "double-buffering" technique to solve
>The specific problem I'm facing is model ORM objects going "stale" (the
>in-memory representation is different than the database due to a change
>from another machine/thread). Typically ORM layers deal with this by
>supporting some form of Versioning on the records so the ORM can
>freshen the cac
First of all, I'm not a Django Dev Team member, but have used ORM technology for years.Singleton objects within an OM context do no scale across multiple machines/VMs. Its pipe dream material. I've saw a demo of this kind of stuff from an OODB vendor in the late nineties and it was impressive, but
Here is a blog article about what core functionality an ORM should
support:
http://pythonnotes.blogspot.com/2004/09/python-orm-tools.html
Specifically, take note of the paragraph that reads:
To implement true object persistence, each object needs a unique
identifier. Each ORM will use a differe
Does anyone from the Django team have any thoughts on this problem?
Am I missing something here?
-Z
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django
I'm sure I must be missing something obvious here folks, but perhaps
someone could shed some light for me.
Could someone please point me to some material on using Django in a
load-balanced environment?
The specific problem I'm facing is model ORM objects going "stale" (the
in-memory representati
20 matches
Mail list logo
