Re: caching questions

[[EMAIL PROTECTED]]

anyone ?

> however, there are two things that I haven't been able to sort
> out on my own:
>
> - the admin site is cached too, which makes it a bit hard to use.
> it might be a middleware ordering problem, but I haven't found a
> working combination. any ideas?
>
> - I would like to explicitly remove pages from the cache, based
> on the URL. is there some public API for this that I haven't found ?


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---

Re: date time errors: please explain?

[tonemcd]

I'm pretty sure that fields defined as DateTimeField in your model are
converted to python datetime objects when read from the database.

That means you can use all the datetime methods on it, like
datetime.timedelta for example.

Check out
http://groups.google.com/group/django-users/browse_frm/thread/8d10d2ca33e18e00/9c747b0894d22fda?q=timedelta=1#9c747b0894d22fda
for more details.


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---

Re: Django in a Load-Balanced environment (ORM issues) ...

[Ivan Sagalaev]

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 of its objects, the objects in my current script start
>tossing exceptions or quietly changing their state.
>
I know 3 common ways dealing with this problem:
- Last write wins (which we have now)
- Validating on save. You get an object, process it, try to save and - 
bang - "data was modified by someone since you last read it, would you 
like to loose your changes"? This is a cheap way but works only with 
user interaction and this is unacceptable in most cases since users 
usually don't like to debug you system.
- Locking for writing. If you plan to modify an object you lock it 
exclusively and other processes wait for you. This affects performance 
on checks "if locked" and on waits for update time that now includes all 
the cycle read-process-update of the updater.

So the first option is not only viable it's actually better in many 
cases (because it's fastest).

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---

date time errors: please explain?

[gizo]

Hoody.

Can anyone tell me why I can use this code with MySQLdb in python, but
not in Django?

  cursor=db.cursor()
  cursor.execute("select date_add('2006-2-24',INTERVAL 1 Month) as
newDate")

django error is: ValueError, unpack list of wrong size

I am completely stumped.

Alternately, is there a way within Django to do this?

ie. a way to change a datefield by a user-defined number of years,
months, or days?
Thanks


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---

Re: Django scalability question

[ZebZiggle]

That's good to know, but as you have stated previously, transactions
alone won't solve this problem. There still needs to be some concept of
versioning on top of the transactions, which isn't trivial
(arguably/perhaps even harder to do right than supporting transaction
wrappers).

Perhaps we need another trouble ticket for versioning?


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---

Re: manage.py vs. django-admin.py

[tomass]

Thanks, that seemed to do it.


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---

Re: Problem and fix with ado_mssql

[Jeremy Dunck]

On 2/28/06, kent <[EMAIL PROTECTED]> wrote:
>
> The only problem with pymssql from my POV is that it is GPL; adodbapi
> is LGPL which is more liberal and closer to Django's license. I looked
> at ticket 1258, it looks like much of that work would apply to adodbapi
> as well. Certainly some of the failing adodbapi tests would be fixed by
> the same changes. Would you be interested in having two working
> adapters if I can get adodbapi to work?

Kent, sorry for not getting back to you sooner -- I meant to first
thing this morning.

Anyway, if you think you can get the backend over adodbapi working,
that'd be great.  I understand your concern about GPL vs. LGPL -- I've
written the pymssql author to see if he'll accept my patches on it--
if not, well, I don't want to maintain a "pymssql for django" package,
really.

There are a few others interested in getting support, too.  I'll CC
you on that in a moment.

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---

FileField in Admin

[MartinG]

I have installed Django on two WinXP machines and created similar test
applications on both. The model for the application "notes" contains
the class "Note", and the class "Attachment", as shown below:

class Note(meta.Model):
note_text = meta.TextField('text')
class META:
admin = meta.Admin()

def __repr__(self):
return self.note_text

class Attachment(meta.Model):
note = meta.ForeignKey(Note, verbose_name="the note",
edit_inline=meta.TABULAR, num_in_admin=3)
Att_file = meta.FileField('file', upload_to = 'dump', core=True)


MEDIA_ROOT is set, and I can create a new note in the admin and attach
a file, which ends up where it should. However, if I open the note
again in the admin, and select "Save" without changing anything, I get
the message "Please correct the errors below", with the file field
highlighted. The message persists even if I select a new file to be
uploaded. What have I done wrong?

Best regards
Martin


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---

Re: Django scalability question

[hugo]

>That said, it is nice to see someone admit that this is a problem. :-)

Actually _that_ was never the problem: the ticket on transactions
(whose absence is the actual culprit in this problem area) is ticket #9
:-)

bye, Georg


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---

Re: Django in a Load-Balanced environment (ORM issues) ...

[Peter Harkins]

-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() so that it checks the
> status field against the status field of the newest object in the
> database, and throw an exception if the numbers aren't in sync. We
> could roll this into Django proper in a generic way if there's a
> demand.

I can see why folks would want this, but I'd like to toss in a vote
against it being on by default. It strikes me as spooky action at a
distance -- because another process possibly on another machine saved
the state of one of its objects, the objects in my current script start
tossing exceptions or quietly changing their state. This would be bad
for an I'm writing that has both short-lived pages and a longer-lived
process that wants to have possibly out-of-sync data to keep track of
state and state changes.

I also think it'd be really surprising (in a bad way) to newbies. It
feels a little like thread programming, where getting variables into a
known state requires some kind of locking.

Note that I'm not saying "don't do it" or "it's always bad", I'm just
asking "please don't do it by default". And to touch on an earlier
topic, I'm all for transaction support.


- --
Peter Harkins  -  http://push.cx


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: If you don't know what this is, it's OK to ignore it.

iD8DBQFEBMLJa6PWv6+ALKoRAjz0AJ9tT89VaTYly2ksc2OU1kSB6t3MTgCfaejL
a7dWe5ddbcECf6VG+hsXQmg=
=7mU0
-END PGP SIGNATURE-

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---

Re: Django in a Load-Balanced environment (ORM issues) ...

[ZebZiggle]

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


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---

Re: Django scalability question

[ZebZiggle]

Hmm, I don't think you could get a cycle short enough to avoid the race
conditions described above. I agree that keeping objects in memory will
not help the problem (as per my original post), but constantly
freshening the object won't work either.

Perhaps single-user is a an unqualified overstatement, but I don't
think you have to look too far to find the cases where it is correct.

That said, it is nice to see someone admit that this is a problem. :-)


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---

Re: Django scalability question

[Ivan Sagalaev]

ZebZiggle wrote:

>I'm sure there are many very large websites using Django, but from what
>I see many are newspaper-style (many reads, few if any writes except by
>the admins). I'd be curious how may sites are doing dynamic updates by
>many concurrent users?
>
It's still not a problem for a typical web app (think of eshops) that 
indeed does many concurrent updates. The thing is that these updates are 
targeted at different data: each user updates its own piece. So another 
condition that should be applied to your problem description is that 
there should be many concurrent updates to shared data.

And even with such updates the problem would exist only with 
applications that keep modified data in memory for later access. Again 
it's not the case for a typical web app where each request does a short 
cycle of read-process-update. Most of the time most of the state is 
stored in a database and not distributed across many concurrent processes.

I do agree that the problem exist. However I don't agree that it's 
common enough to cliam that Django can only support single user scenario :-)

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---

Re: Django in a Load-Balanced environment (ORM issues) ...

[Adrian Holovaty]

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 "double-buffering" technique to solve it. But, it's not going to be
> pretty.
>
> I've considered SqlObjects, but then I would perhaps just cut over to
> TurboGears. A colleague has recommended SqlAlchemy. I'll look at both.

Max did a good job (in his e-mail) of explaining our thoughts on this.
We don't implement this level of super object-instance consistency at
this point because we aim for an 80% solution. The vast majority of
Web sites don't require it.

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() so that it checks the
status field against the status field of the newest object in the
database, and throw an exception if the numbers aren't in sync. We
could roll this into Django proper in a generic way if there's a
demand.

Alternatively, SQLAlchemy solves this problem by implementing an
identity map, which is quite cool. You should be able to use
SQLAlchemy with the rest of Django with no problems at all -- the only
thing you won't be able to take advantage of is the admin framework.

Adrian

--
Adrian Holovaty
holovaty.com | djangoproject.com

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---

Re: Django in a Load-Balanced environment (ORM issues) ...

[Max Battcher]

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 up on TODO lists, but right now it is simply not the
priority that you would like it to be.  Keep in mind that Django
encompasses a lot of uses and as has been pointed out, for the
majority of uses (the majority of website types),
non-"last-write-wins" transaction support is not a priority.  Feel
free to come up with your own solution and submit a patch if you'd
like to get it done sooner, or just wait for the TODO items to move up
in the priority list.

> I think in my case I can isolate the offending code and use some form
> of "double-buffering" technique to solve it. But, it's not going to be
> pretty.

I would again suggest you take a look at the magic-removal branch
.  You could
encapsulate such code in the actual save() call and fake the Django
ORM having that support, and then when Django does provide something
that you are happy with you can pull out your custom save() code and
the rest of your code probably won't notice.

You can even write your own object "Manager" to have fuller control of
object caching and to implement said save()-overload code for several
model classes.

--
--Max Battcher--
http://www.worldmaker.net/
All progress is based upon a universal innate desire on the part of
every organism to live beyond its income. --Samuel Butler

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---

Re: Model Basics

[Max Battcher]

On 2/28/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> Yeah, we talked about this on Sunday at the Django sprint. The
> tentative plan is to introduce a CurrentUserField which is
> special-cased in the admin logic.

How would this be handled in user code?  How would Manipulators deal
with these, ie, would Manipulators have to start taking request.user
in addition to request.POST?  (I'm assuming you've put thought into
how this will effect the proposed changes to Automatic Manipulators,
as well?)

In particular, I have a couple of Models that are created updated
during the save() of other Models (ChangeLogs and Changes) and I
realize this is a special case, but is there any good way to have have
CurrentUser information available to something like the save() without
tying it to only the Admin (ie, still allowing custom forms or
shell-based modifications)?

(On a side note, I could use the ability to have custom
non-Model-Fields (ie, not persisted in the database, only used in the
save() ChangeLog generation) in the Admin, is there an existing way to
do this?)

--
--Max Battcher--
http://www.worldmaker.net/
All progress is based upon a universal innate desire on the part of
every organism to live beyond its income. --Samuel Butler

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---

Re: Django in a Load-Balanced environment (ORM issues) ...

[ZebZiggle]

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 it. But, it's not going to be
pretty.

I've considered SqlObjects, but then I would perhaps just cut over to
TurboGears. A colleague has recommended SqlAlchemy. I'll look at both.

Cheers,
Zeb


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---

Re: limiting foreign key choices in a selection field

[Nebojša Đorđević]

sam wrote:
> My problem is the "category" is determined at run-time, not at module
> definition time. How to do that? Thanks.

I'm missed 'When I make a form to enter the "part" information' part :)

From: http://www.djangoproject.com/documentation/forms/

something like this (untested):

class ContactManipulator(formfields.Manipulator):
def __init__(self, category):

maker_choices = []
for dct in makers.get_values(fields=['id', 'name'], 
category__exact=category):
maker_choices.append((dct['id'], dct['name']))
self.fields = (
formfields.SelectField(field_name="maker", choices=maker_choices),

)

So you can decide which category to show when creating a form in your view 
function, and use this instead of AddManipulator.

Hope that helps.

-- 
Nebojša Đorđević - nesh
Studio Quattro - Niš - SCG
http://studioquattro.biz/
http://djnesh.blogspot.com/  |  http://djnesh-django.blogspot.com/ |  
http://djangoutils.python-hosting.com/
Registered Linux User 282159 [http://counter.li.org]

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---

Re: Model Basics

[Adrian Holovaty]

On 2/28/06, DaveW <[EMAIL PROTECTED]> wrote:
> I see that ticket #1268 has been closed as WontFix - threadlocal is
> felt to be to heavyweight a solution. Unfortunately, some mechanism for
> this is going to be needed for Django to be used in many corporate
> environments - has anyone had any other thoughts about how to implement
> this?

Yeah, we talked about this on Sunday at the Django sprint. The
tentative plan is to introduce a CurrentUserField which is
special-cased in the admin logic.

Adrian

--
Adrian Holovaty
holovaty.com | djangoproject.com | chicagocrime.org

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---

Re: Model Basics

[DaveW]

I see that ticket #1268 has been closed as WontFix - threadlocal is
felt to be to heavyweight a solution. Unfortunately, some mechanism for
this is going to be needed for Django to be used in many corporate
environments - has anyone had any other thoughts about how to implement
this?


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---

Re: Django scalability question

[ZebZiggle]

Hugo/Georg is exactly correct.

I'm sure there are many very large websites using Django, but from what
I see many are newspaper-style (many reads, few if any writes except by
the admins). I'd be curious how may sites are doing dynamic updates by
many concurrent users? In a read-only / content / presentation oriented
site (as Hugo calls them) you won't run into this problem.

The banking example above or my example across two machines is exactly
the sort of problem that Django doesn't support.

"Of *course* you'd expect that obj2.data != obj1.data"

No ... I'd *absolutely* expect obj2.data == obj1.data or it should
throw an exception on the second write. That's what Hibernate supports
beautifully.


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---

Re: limiting foreign key choices in a selection field

[Nebojša Đorđević]

sam wrote:
> I have a model such as:
> 
> class Part:
> maker = ForeignKey(Maker)
> ..
> 
> When I make a form to enter the "part" information, if I user standard
> AddManipulator, maker will become a selection list of all possible
> makers. What if I only want to show a sub-list of makers that belong to
> a specific "category". I suppose I should use custom manipulators, but
> don't know exactly how to do. Pls help!


How about:

maker = meta.ForeignKey(Maker, limit_choices_to={'category__exact': 'foo'})

-- 
Nebojša Đorđević - nesh
Studio Quattro - Niš - SCG
http://studioquattro.biz/
http://djnesh.blogspot.com/  |  http://djnesh-django.blogspot.com/ |  
http://djangoutils.python-hosting.com/
Registered Linux User 282159 [http://counter.li.org]

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---

Re: Django scalability question

[hugo]

>Of *course* you'd expect that obj2.data != obj1.data -- Django's not
>going to be able to hide the fact that you're using a database from you
>(nor should it).

Think distributed: two requests updating the same data concurrently.
Last write wins. Data might not be what you expect, as you can't make
sure that you have the version you directly read before updating. This
is the simple scenario. Often this doesn't matter, as "last write wins"
is quite acceptable. But sometimes - for example if you do financial
transactions or shop stuff - this might be quite undesirable. But even
then it might not hit you, as this is a solely update-related problem -
it won't happen with inserts, as you usually have automatically
generated id's and so concurrent inserts will get separate id's.

And it can't be really solved without transactions, as you would need
to be able to make sure that your fetched object is still the correct
version that's in the database. Think for example about something like
this:

account = banking.get_account(pk=4711)
... do some calculation on what to store in the account
account.amount += result_of_calcuation
... do maybe some more calculations for other stuff
account.save()

You can't be sure that your account still has the same amount when you
do the += and the save is done, so you can't make sure that you don't
stomp on updates others have already done in between. And just "move
the read/update/save calls into one spot in the code" won't cut it - it
would just make it less probable to hit this problem, but given a high
enough update rate you will still hit it.

Actually I had exactly that problem in a small project where I used the
Django ORM out of laziness and did hit exactly this - I was collecting
sum data on object values in a cumulative table. Of course I switched
that to a simple SQL trigger mechanism, as it wasn't much more than
just a python-written triggern (it was actually a _post_save code on
the detail object that kept tallies of object kinds on the collection
object). The SQL trigger was executed in the same transaction as the
update SQL and so the problem was solved.

But the account/amount problem above can't be solved on SQL level alone
- it's fully application code depending and so you are currently fubar.
At least unless we get transactions ;-)

Granted, in most content-oriented and presentation-oriented
applications you don't hit this problem - I did hit it because the
relevant application needed a fast overview of data in the catalog and
the items themselves where too many to count them on view time, so I
needed the tallies. Other content and presentation oriented sites
aren't that update-heavy to start with, and if they are, it's mostly
people updating different parts of the database (and if two update the
same thing, "last write wins" is the expected outcome anyway). So this
is more a problem for people who do more processing-oriented sites.

bye, Georg


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---

limiting foreign key choices in a selection field

[sam]

I have a model such as:

class Part:
maker = ForeignKey(Maker)
..

When I make a form to enter the "part" information, if I user standard
AddManipulator, maker will become a selection list of all possible
makers. What if I only want to show a sub-list of makers that belong to
a specific "category". I suppose I should use custom manipulators, but
don't know exactly how to do. Pls help!


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---

Re: Django scalability question

[James Bennett]

On 2/28/06, ZebZiggle <[EMAIL PROTECTED]> wrote:
> Sorry, but I don't think Django will work in anything but a single user
> environment, or multi-users only doing read-only access. Unless someone
> from the Django team can clarify. Please read my thread on this issue
> ... it's a big concern for me.

Django's original install base was a few sites that, between them, do
a few million hits. Django's current install base is everything from
personal blogs to high-traffic applications at the Washington Post.
While I don't mean to be insulting, this would seem to indicate that
if you can't get Django to scale, your problem is not in Django.


--
"May the forces of evil become confused on the way to your house."
  -- George Carlin

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---

Re: code mod to get raw admin template output

[Adrian Holovaty]

On 2/24/06, hsitz <[EMAIL PROTECTED]> wrote:
> Back in middle of last year Adrian Holovaty posted some very helpful
> information on how to get the raw output of admin templates for use as
> basis for your own views.  I'm a newbie trying to get my head around
> Django, and it seems the code has been refactored since then.  Is it a
> simple matter to reenable this in latest version?

Hi Herbert,

Yes, the admin code was refactored between 0.90 and 0.91. The
fundamental change was to put the template-generation logic in actual
*template* files rather than generating the template in the memory.
This makes it easier to override particular sections of admin code, at
the cost of being way more abstract and harder to understand. You can
poke around the templates in django/contrib/admin/templates/admin.

Adrian

--
Adrian Holovaty
holovaty.com | djangoproject.com

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---

Re: Django scalability question

[Jacob Kaplan-Moss]

On Feb 28, 2006, at 7:49 AM, ZebZiggle wrote:
> Sorry, but I don't think Django will work in anything but a single user
> environment, or multi-users only doing read-only access. Unless someone
> from the Django team can clarify.

I'd be glad to:

I have three web servers hitting the same database server.  Some
content is shared; some is not.  It works perfectly.

I really don't know what else to say about this; you've complained that
you're having problems, but I don't see any details of what those
problems are, and I've never experienced any of them in practice.

In your example::

obj1 = objects.get_object(pk=1)
obj2 = objects.get_object(pk=1)
obj1.data = 1
obj1.save()

Of *course* you'd expect that obj2.data != obj1.data -- Django's not
going to be able to hide the fact that you're using a database from you
(nor should it).

If this is actually a problem for you -- and not just a theoretical one
-- please give me more details so I don't have to assume that this is
just FUD.

Jacob


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---

Re: Django in a Load-Balanced environment (ORM issues) ...

[Ijonas Kisselbach]

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 look how far OODBs have progressed (answer: not very).
Real-life ORM, typically provides different ways of handling stale, transient, and persistent objects. HIbernate, probably the most well-known ORM tool of today, supports some versioning
 features by adding "system columns" to tables to prevent old data clobbering fresh data.What you're looking for is for the RDB  to push change events to an ORM-maintained cache in the application server layer, 
e.g. Django. Microsoft SQL Server 2005 is, AFAIK, the only RDBMS which dispatches these "cache update events" to the application layer. I don't know how successful this new technology is but its sounds expensive in terms of resources.
The problem you describe is a classic ORM, and typically you have to assume worst-case scenario and code around the problem by using transactions and refreshing your objects.Have you considered Python's SQLObject library ? You might get better mileage.
Hope it helps,IjonasOn 2/28/06, ZebZiggle <[EMAIL PROTECTED]> wrote:
Here is a blog article about what core functionality an ORM shouldsupport: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 uniqueidentifier. Each ORM will use a different approach here. However, oneissue that is common to all ORMs is how to handle multiple copies of
the same object. For the sake of consistence, objects should besingletons. If the ORM tool doesn't do it automatically, then it's upto the programmer to make sure that no multiple copies of the sameobject exist at the same time, avoiding concurrency and consistency


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]  For more options, visit this group at http://groups.google.com/group/django-users  -~--~~~~--~~--~--~---

Re: Django in a Load-Balanced environment (ORM issues) ...

[ZebZiggle]

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 different approach here. However, one
issue that is common to all ORMs is how to handle multiple copies of
the same object. For the sake of consistence, objects should be
singletons. If the ORM tool doesn't do it automatically, then it's up
to the programmer to make sure that no multiple copies of the same
object exist at the same time, avoiding concurrency and consistency
issues.


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---

Re: Django scalability question

[ZebZiggle]

Sorry, but I don't think Django will work in anything but a single user
environment, or multi-users only doing read-only access. Unless someone
from the Django team can clarify. Please read my thread on this issue
... it's a big concern for me.

http://groups.google.com/group/django-users/browse_frm/thread/56698424ae3708ea

Thanx,
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-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---

Re: Problem and fix with ado_mssql

[kent]

The only problem with pymssql from my POV is that it is GPL; adodbapi
is LGPL which is more liberal and closer to Django's license. I looked
at ticket 1258, it looks like much of that work would apply to adodbapi
as well. Certainly some of the failing adodbapi tests would be fixed by
the same changes. Would you be interested in having two working
adapters if I can get adodbapi to work?

Kent


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---