Re: Database race conditions when using multiple processes
James Bennett wrote: > On 10/16/06, gabor <[EMAIL PROTECTED]> wrote: > > would you use something in the db? (from what i know about transactions > > (very little :), they "solve" the potential conflicts by simply > > reporting an error-condition to one of the "writers", so then he has to > > retry. but is there some simply (multiprocess-usable) way to lock (as in > > "wait until this guy is finished")? > > http://www.postgresql.org/docs/8.1/static/sql-lock.html This is PostgreSQL specific. There seems also to be something like that for MySQL: http://dev.mysql.com/doc/refman/5.0/en/lock-tables.html (it looks like you have to do an UNLOCK TABLES on MySQL, whereas PostgreSQL releases the lock at transaction end). Shouldn't there be a function built-in into Django that locks the table (if the database supports it)? IMHO functions like get_or_create() should try to lock and unlock the table automatically. I am not doing critical operations like transferring money, but I noticed that the race condition happens quite often when using get_or_create and a lot of AJAX requests, so I need to find a solution. I will try using PostgreSQL instead of SQLite, maybe this will reduce the probability of the race condition to happen ;-) tom --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: Why doesn't models.Manager implement __iter__?
Does this caching of QuerySets live beyond one request ? I assume each thread gets its own cache, right ? For us poor users of shared hosting, where we're using multiple processes that are killed and respawned many times, this isn't very helpful... Unless I haven't understood all this, in that case please explain :) This should go in the docs, as it can have unexpected nasty side-effects... --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: feature request: Bonjour support
Hi, There is a pyzeroconf module [1] and it seems pretty easy to use [2]. Just find in the code where it does assign the IP address, and insert the 15 lines you need to advert the service. Should be pretty easy. Now, the problemis, Django tries to use as little dependencies as possible, and this would be one. But there has not been any new release since a year and a half, so it might be pretty stable. Enjoy, G [1] http://sourceforge.net/projects/pyzeroconf [2] http://www.amk.ca/python/zeroconf On 10/17/06, evariste <[EMAIL PROTECTED]> wrote: > > The technology formerly known as Rendezvous, yes. When you start a > turbogears project with start-projectname.py, tg tells Bonjour of its > existence and you can view it simply by pulling it down from the > Bonjour menu in Safari's Bookmarks Bar. If the project is stopped, the > site is removed from Bonjour. It's way easier than typing > http://localhost:port in the address bar. It would be nice if I could > do python manage.py runserver, then just switch to Safari and pull the > site down from the Bookmark Bar. > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: Why doesn't models.Manager implement __iter__?
orestis schrieb: > Does this caching of QuerySets live beyond one request ? I assume each > thread gets its own cache, right ? > > For us poor users of shared hosting, where we're using multiple > processes that are killed and respawned many times, this isn't very > helpful... > > Unless I haven't understood all this, in that case please explain :) > > This should go in the docs, as it can have unexpected nasty > side-effects... The cache is within one particular instance of QuerySet. As soon as the QuerySet is gone, the cache is gone. Clearer now? Michael --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: Database race conditions when using multiple processes
Thomas Steinacher schrieb: > James Bennett wrote: >> On 10/16/06, gabor <[EMAIL PROTECTED]> wrote: >>> would you use something in the db? (from what i know about transactions >>> (very little :), they "solve" the potential conflicts by simply >>> reporting an error-condition to one of the "writers", so then he has to >>> retry. but is there some simply (multiprocess-usable) way to lock (as in >>> "wait until this guy is finished")? >> http://www.postgresql.org/docs/8.1/static/sql-lock.html > > This is PostgreSQL specific. There seems also to be something like that > for MySQL: http://dev.mysql.com/doc/refman/5.0/en/lock-tables.html (it > looks like you have to do an UNLOCK TABLES on MySQL, whereas PostgreSQL > releases the lock at transaction end). Speaking of this, I also miss a way to do SELECT ... FOR UPDATE. > Shouldn't there be a function built-in into Django that locks the table > (if the database supports it)? IMHO functions like get_or_create() > should try to lock and unlock the table automatically. Oh no! Are you aware of the impact you can get when you lock a table under heavy load? This is really very specific of your application. Maybe for your case it's fine to lock the entire table. Others might specify more rigid unique constraints and deal with the exceptions; sometimes a SELECT ... FOR UPDATE is the right thing. > I am not doing critical operations like transferring money, but I > noticed that the race condition happens quite often when using > get_or_create and a lot of AJAX requests, so I need to find a solution. It seems you need to spend more thoughts on multi user issues within your application. It's easy to fall for that in the beginning, but you need to deal with concurrent access. You must be aware for all transactions what impact other transactions can have. There is no silver bullet ... (please repeat ;-) > I will try using PostgreSQL instead of SQLite, maybe this will reduce > the probability of the race condition to happen ;-) Hmm, this might be a first step, but it won't magically solve all multi user issues. This *is* hard stuff. Michael --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: Why doesn't models.Manager implement __iter__?
Yep :) Thanks! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
XHTML vs. HTML4 and csrf middleware in particular
Hi, I have to start with a little background. There's the still interesting issue of what media type you give to your pages and whether to use html4 or xhtml. Large part of Django seems to use xhtml, and I like it somehow better than html, so I use it and give to browsers that accept it application/xhtml+xml as media type (and to others I feed the same input but call it text/html). Now, when I use the great csrf middleware from contrib, it outputs this error message when it deduces that there's an csrf attack, and without any template around it: 403 ForbiddenCross Site Request Forgery detected. Request aborted. If you try this with a firefox and media type application/xhtml+xml, you only get a message that the server has given us incorrect xhtml. And right so. So I changed it to: http://www.w3.org/1999/xhtml"; xml:lang="en">403 ForbiddenCross Site Request Forgery detected. Request aborted. Now to my question: What is the current policy? Should this output be xhtml conform or not? The point is, and that goes above the csrf message, I don't know if it's a good idea or not to use xhtml at all. You need to call it text/html for IE6 and before, but to get any benefit from xml (i.e., to see your errors immediately and get a more rigid interpretation from the browser), you need to call it application/xhtml+xml at least to the browser that understand it. But then you get interesting effects on stylesheets and JavaScript: stylesheets are also interpreted a little bit differently (e.g., case matters with xhtml but not with html; java script is expected to use the namespace stuff) I have this under control for myself, but I really don't know if it's a good idea to propose xhtml in general. Michael --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: XHTML vs. HTML4 and csrf middleware in particular
Hi Michael, On 17 Oct 2006, at 12:00, Michael Radziej wrote: > Large part of Django seems to use xhtml, and I like it somehow > better than html, so I use it and give to browsers that accept it > application/xhtml+xml as media type (and to others I feed the same > input but call it text/html). this is slightly orthogonal to your question, but bear in mind that when served as application/xhtml+xml the page is parsed differently from the browser. For example, Javascript requires namespace-aware methods for DOM manipulation on application/xhtml+xml documents, so your scripts will likely break from one version to the other. This is not the only problem, many others have been outlined in these two articles that I strongly advice you to read: http://hixie.ch/advocacy/xhtml http://webkit.org/blog/?p=68 Since you stated you’re serving the same content with different MIME types, you may be on a slippery slope there. HTH, -- Antonio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: XHTML vs. HTML4 and csrf middleware in particular
Antonio Cavedoni schrieb: > Hi Michael, > > On 17 Oct 2006, at 12:00, Michael Radziej wrote: >> Large part of Django seems to use xhtml, and I like it somehow >> better than html, so I use it and give to browsers that accept it >> application/xhtml+xml as media type (and to others I feed the same >> input but call it text/html). > > this is slightly orthogonal to your question, but bear in mind that > when served as application/xhtml+xml the page is parsed differently > from the browser. Antonio, you're probably suffering from a severe read-only-first-paragraph syndrome here. Proposed cure is to read email again until bottom hits ;-) Michael --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: XHTML vs. HTML4 and csrf middleware in particular
On 10/17/06, Michael Radziej <[EMAIL PROTECTED]> wrote: > What is the current policy? Should this output be xhtml conform > or not? Policy for Django? There isn't one, so far as I know. Policy for the web in general? Good luck with that :) > The point is, and that goes above the csrf message, I don't know > if it's a good idea or not to use xhtml at all. You need to call > it text/html for IE6 and before, but to get any benefit from xml > (i.e., to see your errors immediately and get a more rigid > interpretation from the browser), you need to call it > application/xhtml+xml at least to the browser that understand it. > But then you get interesting effects on stylesheets and > JavaScript: stylesheets are also interpreted a little bit > differently (e.g., case matters with xhtml but not with html; > java script is expected to use the namespace stuff) I have this > under control for myself, but I really don't know if it's a good > idea to propose xhtml in general. I think XHTML is fine, so long as it's in the hands of someone who really knows how to use it. There aren't a whole lot of people like that, though, so I don't think XHTML is appropriate in most of the cases where it's used. Of course, I may be accused of bias :) -- "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 developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: Database race conditions when using multiple processes
Michael Radziej wrote:
> It seems you need to spend more thoughts on multi user issues
> within your application. It's easy to fall for that in the
> beginning, but you need to deal with concurrent access. You must
> be aware for all transactions what impact other transactions can
> have. There is no silver bullet ... (please repeat ;-)
>
> > I will try using PostgreSQL instead of SQLite, maybe this will reduce
> > the probability of the race condition to happen ;-)
>
> Hmm, this might be a first step, but it won't magically solve all
> multi user issues. This *is* hard stuff.
Simply switching to PostgreSQL didn't solve anything. The race
condition was still there.
I am not sure but I think that a lock would be okay for my application,
as I don't want to deal with exceptions. What do you think about the
following code?
def process(request):
if request.POST.get('text'):
cursor = connection.cursor()
# Acquire a lock
cursor.execute('LOCK TABLE testapp_test IN ACCESS EXCLUSIVE
MODE')
t =
models.Test.objects.get_or_create(str=request.POST.get('text'))[0]
# Release the lock
transaction.commit()
return HttpResponse('%s %s' % (request.POST.get('text'), t.id))
else:
return HttpResponse('Missing argument')
process = transaction.commit_manually(process)
tom
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@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-developers
-~--~~~~--~~--~--~---
Re: Re: Database race conditions when using multiple processes
On 10/17/06, Thomas Steinacher <[EMAIL PROTECTED]> wrote: > Shouldn't there be a function built-in into Django that locks the table > (if the database supports it)? IMHO functions like get_or_create() > should try to lock and unlock the table automatically. No, no, a thousand times no :) Even though modern database engines do a few things to help avoid the worst of the problems, automated locking is fraught with peril. Let's take a simple example... assume you have a UserProfile model tied one-to-one to User, and the following happens: Request A wants to create a new user, so it locks the User table for writing and, because it knows it needs to create a UserProfile as well, tries to lock that table. At the same time, request B also wants to create a new user, but it gets to the UserProfile table first and locks it, then tries to lock the User table. And... your application dies. Request A won't release the User table until it can get a lock on the UserProfile table, but request B won't release the UserProfile table until it can get a lock on the User table. You are now in the delightful situation known as "deadlock", where nothing can go forward because everybody's waiting for locks that can never happen. There are ways to reduce the likelihood of a deadlock (see any of the solutions to the "dining philosophers problem", for example), but automatic locking by the framework introduces so much additional complexity and so many additional pitfalls that I don't think it's worth the payoff. If you're writing an application which has parts that engage in heavily concurrent writing, you're going to need to learn your database's locking and isolation features, and take advantage of them (incidentally, transaction isolation is often simpler to work with than locking, because it doesn't raise the possibility of deadlocks). -- "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 developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: Database race conditions when using multiple processes
James Bennett schrieb: > On 10/17/06, Thomas Steinacher <[EMAIL PROTECTED]> wrote: >> Shouldn't there be a function built-in into Django that locks the table >> (if the database supports it)? IMHO functions like get_or_create() >> should try to lock and unlock the table automatically. > > No, no, a thousand times no :) I bet you mean that get_or_create shouldn't lock the table. That's really not a good idea. But what about a database independent command for locking the table? I'm not sure if it's really worth, but it's certainly not a "thousand times no", or did I miss anything? (And, by the way, What about SELECT ... FOR UPDATE ) Michael --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: Re: Database race conditions when using multiple processes
On 10/17/06, Michael Radziej <[EMAIL PROTECTED]> wrote: > I bet you mean that get_or_create shouldn't lock the table. > That's really not a good idea. I meant Django should never implicitly/automatically lock a table; if you decide you need to lock, you should have to explicitly call something. I'm ambivalent on whether we should provide a syntax for a "database independent" lock/unlock, but I think it could be problematic to design -- for one thing, I'm not sure where it would fit, and for another I'm not sure how best to implement it (since, for example Postgres automatically releases the lock on COMMIT or ROLLBACK, but MySQL requires you to explicitly UNLOCK) -- "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 developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
defining outer joins
Hi,
I was looking for an easy way to define extra outer joins. It
turned out that it's easy to extend the QuerySet.extra method
with a 'joins' argument used like this:
notes = Note.objects.select_related().extra(
joins=['''left outer join %s rel1 on
rel1.id=%s.release_beginn_id'''
% (Release._meta.db_table, Note._meta.db_table),
'''left outer join %s rel2 on
rel2.id=%s.release_behoben_id'''
% (Release._meta.db_table, Note._meta.db_table)],
where=['''((%(notes_table)s.release_beginn_id is null or
rel1.sort_value <= %(sort_value)d)
and (%(notes_table)s.release_behoben_id is null or
rel2.sort_value > %(sort_value)d))'''
% {'sort_value': version, 'notes_table':
Note._meta.db_table}])
(I left out the db name quoting since it doesn't contribute much
to this example.)
The patch is surprisingly small:
http://code.djangoproject.com/attachment/ticket/2922/extra_joins.diff
I guess this is currently under a freeze. I just wanted to bring
it up for discussion. If there's serious interest, I can flesh it
out (docs, testcases) later when the winter^H^H^H^H^H^H^H freeze
is over.
Michael
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@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-developers
-~--~~~~--~~--~--~---
Re: Database race conditions when using multiple processes
Michael Radziej wrote: > > What about > SELECT ... FOR UPDATE > ) Michael, I know you're already aware of this (heck, you're CCed on the ticket), but for others... I created a patch in ticket http://code.djangoproject.com/ticket/2705 to allow a .for_update() modifier to be applied to a QuerySet, so you can do: something = models.Something.objects.filter(id=333).for_update().get() This wouldn't solve the get_or_create() problem, but it is helpful for a lot of other use cases. --Ben --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: XHTML vs. HTML4 and csrf middleware in particular
On 17 Oct 2006, at 12:21, Michael Radziej wrote: > Antonio, you're probably suffering from a severe read-only-first- > paragraph syndrome here. Proposed cure is to read email again until > bottom hits ;-) Michael: you’re right, I’m a moron :-) Sorry for wasting everyone’s time. Cheers. -- Antonio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: Proposal: Forms and BoundForms
I'm sorry to say that I missed the thread "Proposal: Forms and
BoundForms" last month. I'm very interested in the topic, largely
because, having run out of patience with manipulators, I had written
code to handle form definition, validation, and rendering that is
similar to the proposals described in that thread. In developing this
library, I was focusing mainly on providing useful integration between
forms and models (including "nested forms"), and customisability of
forms. I'll describe this here, focusing mostly on the needs or
decisions which haven't been discussed in that thread already. I hope
that some of this will be of use for the manipulator replacement work
that is in progress.
I was motivated in creating this to fulfill these needs that I had that
manipulators weren't fully suitable for:
A. To allow easy declarative form creation, as well as customisation of
the default form for a model.
B. To unify adding/changing model instances. Adding and changing are
processed identically, with only the form defaults being different.
C. To allow a form to be easily generated and handled for a model
hierarchy -- i.e. a single model instance, and other instances related
via ManyToManyFields and ForeignKeys in either direction; and
supporting model validation.
D. To make it easy to customise the rendering of a form or form field.
E. To allow forms with validation to be used without being tied to a
model class/instance -- i.e. to work with dicts and lists.
For (A), I implemented the unbound/bound distinction with the natural
class/instance distinction: a Form subclass defines the form structure
and validation, and an instance of the class is that form, "bound" with
data, and errors (if it has been validated). Similarly, a Widget
subclass (a form field) defines the widget's attributes (name, size,
choices list), and a Widget instance has data and errors. All
customisation of forms and widgets is done through subclassing, with an
alter() method providing a convenient helper for small changes.
For example, assume a UserProfile model that has 'username',
'fullname', and 'email' TextFields, and a 'group' ForeignKey. The
automatically generated default form for this model would have a
TextWidget for the first three fields, and a SelectField for the
group_id, with a list of the available groups.
# Never let the username be edited, and use a custom widget for the
# email field
class EditProfileForm(Profile.default_form):
username = None
email = EmailWidget.alter(maxlength=20)
# Only let admin users edit the group
if not request.user.is_admin():
EditProfileForm = EditProfileForm.alter(group_id=None)
For (B): handling the request involves creating a form instance with
default data, updating that with POST data (if applicable), processing
changes, and rendering the form if unsubmitted or errors.
# If we were adding a profile here, we'd just use Profile()
profile = Profile.objects.get(id=whatever)
form = EditProfileForm(profile)
if request.POST:
form.update_data(convert_post_data(request.POST))
form.process_input_data()
if not form.has_errors():
return HTTPResponseRedirect("/profile/")
return render_to_response("profile.html", {'form': form})
Since the base Form class is ignorant of models (E), and only uses a
dict to store its data, there is a ModelForm subclass that extracts
data from a model instance (and related instances) to fill in the
widgets declared in the form. A default_form descriptor is added to
the models.Model class to generate a form automatically -- but for
convenience, if a default_form class is declared in the model, it will
be used instead (there were some technical hoops to jump through with
this, but I'll gloss over that).
(C), integration with models, is the trickiest part. as implemented,
there are four distinct types of widget, each corresponding to a
different data structure or relation type:
A simple widget corresponds to a simple data type (int, string) or, for
a model instance, a TextField, IntegerField, etc. -- or the
fieldname_id attribute for a ForeignKey relation.
A widget with its has_form attribute set corresponds to a dict, or the
fieldname attribute for a ForeignKey relation to another model; the
SubForm Widget subclass handles this with another Form class:
class EditProfileForm(Profile.default_form):
home_address = SubForm.alter(form=Address.default_form)
# Now we can render form.address.street in a template, and so on
A widget with its has_list attribute set corresponds to a list, or a
ManyToMany or reverse ForeignKey relation to another model, when
selecting from the existing instances, and not editing them inline. A
multi-select list widget handles these.
Finally, a widget with both has_list and has_form corresponds to a list
of dicts, or a ManyToMany or reverse ForeignKey relation, edited
inline. A SubFormList widget is used for this.
Re: bump: give Gabor (or somebody else) a unicode branch in svn
Malcolm Tredinnick wrote: > And my apologies to use, JP: I still haven't gotten around to reviewing > all the changes as I promised I would. It's not forgotten, more that > Life has gotten in the way of Fun Projects a lot lately and there aren't > enough hours in the day. No need to apologize. The same applies over here. It's been a very busy 6 weeks or so, some good busy and some awful busy, and my attention has been anywhere but on Fun Projects. So don't worry about it; review it when you get a chance, and if interest remains I'll merge it back up with trunk HEAD and try to find time to fix or at least document the test failures with sqlite and mysql. Thanks, JP --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: Call for testing: New setup.py
Hi, one diff for MANIFEST.in. The docs/*.txt of bdist_rpm are missing! Regards, Dirk -- GMX DSL-Flatrate 0,- Euro* - Überall, wo DSL verfügbar ist! NEU: Jetzt bis zu 16.000 kBit/s! http://www.gmx.net/de/go/dsl --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~--- Index: MANIFEST.in === --- MANIFEST.in (Revision 3908) +++ MANIFEST.in (Arbeitskopie) @@ -1,6 +1,7 @@ include AUTHORS include INSTALL include LICENSE +recursive-include docs * recursive-include django/conf/locale * recursive-include django/contrib/admin/templates recursive-include django/contrib/admin/media
Re: feature request: Bonjour support
Not to mention it's only going to satisfy an extremely small niche. How many people are actually developing Django apps in Safari on OS X? Most developers I know on OS X (myself and my office included) aren't using Safari in any capacity. Seems like adding complexity and dependencies for no good gain. You say it's just as easy as pulling down the bookmark bar in Safari, but in my browser (Firefox) I just type "lo" and the bar autocompletes for me--I think Safari does this too, right? I don't think I've fully typed out "localhost:8000" in quite a while :) -- Clint Ecker | STONE WARD 440 N. Wells, Suite 750, Chicago, IL 60610 Boston | [ Chicago ] | Little Rock www.stoneward.com On 10/17/06, Guillermo Fernandez Castellanos <[EMAIL PROTECTED]> wrote: > > Hi, > > There is a pyzeroconf module [1] and it seems pretty easy to use [2]. > Just find in the code where it does assign the IP address, and insert > the 15 lines you need to advert the service. Should be pretty easy. > > Now, the problemis, Django tries to use as little dependencies as > possible, and this would be one. But there has not been any new > release since a year and a half, so it might be pretty stable. > > Enjoy, > > G > > [1] http://sourceforge.net/projects/pyzeroconf > [2] http://www.amk.ca/python/zeroconf > > On 10/17/06, evariste <[EMAIL PROTECTED]> wrote: > > > > The technology formerly known as Rendezvous, yes. When you start a > > turbogears project with start-projectname.py, tg tells Bonjour of its > > existence and you can view it simply by pulling it down from the > > Bonjour menu in Safari's Bookmarks Bar. If the project is stopped, the > > site is removed from Bonjour. It's way easier than typing > > http://localhost:port in the address bar. It would be nice if I could > > do python manage.py runserver, then just switch to Safari and pull the > > site down from the Bookmark Bar. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: feature request: Bonjour support
Turbogears just uses the command line tools if they are available, no need to drag in any library dependencies. Another advantage of this approach is that it works on any platform with the bonjour command line tools, not just the mac. You can see it in action here: http://www.turbogears.org/svn/turbogears/trunk/turbogears/startup.py Look for 'def start_bonjour():" cheers, mick --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: feature request: Bonjour support
On Oct 17, 2006, at 11:50 PM, Michael Twomey wrote: > Turbogears just uses the command line tools if they are available, no > need to drag in any library dependencies. Another advantage of this > approach is that it works on any platform with the bonjour command > line tools, not just the mac. > > You can see it in action here: > http://www.turbogears.org/svn/turbogears/trunk/turbogears/startup.py > > Look for 'def start_bonjour():" That's one neat idea we could learn from TG. With the TG's code as an example, it shouldn't be hard to put up a patch. －Cheng Zhang http://www.ifaxian.com 1st Django powered site in Chinese ;-) http://www.aiyo.cn Our 2nd Django powered site in Chinese --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: Call for testing: New setup.py
works here, python 2.5, linux x86_64 (gentoo) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: Call for testing: New setup.py
Works on Windows 2003 Server SP1 + Python 2.4.2 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: Call for testing: New setup.py
DavidA wrote: > Works on Windows 2003 Server SP1 + Python 2.4.2 I spoke too soon. I tried to run 'manage.py test' and it complained about an invalid action so I poked around and the management.py in C:\Python24\lib\site-packages\django\core was different than the one in the SVN checkout directory (that I had just done an install from). I figured it installed the old stuff in the build directory so I remove the build directory and re-ran 'setup.py install' and now I get this error: C:\Django\trunk>setup.py install running install running build running build_py running build_scripts creating build creating build\scripts-2.4 copying and adjusting django\bin\django-admin.py -> build\scripts-2.4 running install_lib warning: install_lib: 'build\lib' does not exist -- no Python modules to install running install_scripts copying build\scripts-2.4\django-admin.py -> C:\Python24\Scripts running install_data C:\Django\trunk> I tried manually creating 'build\lib' but that didn't help (it still doesn't build or install). I also tried 'setup.py build' and it does nothing. I then tried removing the django installation directory in lib\site-packages and it still won't install anything. Now I've sort of hosed myself - guess I'll downgrade... -Dave --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: Call for testing: New setup.py
DavidA wrote: > I spoke too soon. I _really_ spoke too soon. I tried again as 'python setup.py install' rather than 'setup.py install' and it worked. For some reason my file type mapping on this particular Win box was mucked up. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Modification in the django.db.backends.postgresql.base
Hi, Trying to make Django to use really only ONE connection to ONE process (like 1000 Threads using 1 connection) I've altered postgresql backend at base.py. The beta (aka bugged) version is here: http://pastebin.com/808647 My question is if this alteration (turn the connection variable to be a Class-attribute instead of Instance-attribute) would generate some problem in the future. ps.: I know that I don't close connection, but this is not my major problemps2.: I need this a lot becouse I'm using FreeBSD, and it start only 50 connections simultaneously, but my system use 100+ connection alive-- SDM UnderlinuxGarimpar.com--PEP-8Só existem 3 tipos de pessoas no mundo, as que sabem contar, e as que não sabem. CPFL - Compania Piratininga de FALTA de Luz (6 vezes em 5 dias!!) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: Data for globalization
I see that it isn't interesting for django developers so "I go away with the music to another part". In the first I prefer to work with another community where there is more support. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: Data for globalization
On 10/18/06, GinTon <[EMAIL PROTECTED]> wrote: > > I see that it isn't interesting for django developers so "I go away > with the music to another part". > > In the first I prefer to work with another community where there is > more support. Don't read too much into the lack of response; the core developers are all very busy at the moment. What you have suggested is the start of an interesting idea, but light on detail, a long way away from a finished implementation. Without some concrete details, it's a little difficult to have a discussion. If you want to suggest this as an enhancement, open a ticket. That way, the idea isn't lost, and if someone has some spare time, or we are looking for new features for version X, the idea might be implemented. If you want to expedite the process of getting the feature implemented, provide the changes as patches against the development tree, with documentation, examples and unit tests. Yours, Russ Magee %-) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: Modification in the django.db.backends.postgresql.base
On 17/10/06, Rafael SDM Sierra <[EMAIL PROTECTED]> wrote: > ps2.: I need this a lot becouse I'm using FreeBSD, and it start only 50 > connections simultaneously, but my system use but you can change that and default, postgres support 100 connections (2 for superuser) > -- http://www.advogato.org/person/mgonzalez/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: defining outer joins
On 10/17/06, Michael Radziej <[EMAIL PROTECTED]> wrote: > > I guess this is currently under a freeze. I just wanted to bring > it up for discussion. If there's serious interest, I can flesh it > out (docs, testcases) later when the winter^H^H^H^H^H^H^H freeze > is over. You can already specify the join type using Q objects. When you invoke get_sql on a Q object, it returns a tuple, the first argument of which is 'joins', a sorted dictionary that describes the joined table name, join type, and join condition. It's not a heavily advertised feature, so there isn't much documentation; if you want an example, line 840 of query.py shows the addition of a join to the sql results. Using this approach also means that you can keep using Django query syntax for most of your query, rather than just inserting a block of SQL. Yours, Russ Magee --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: Modification in the django.db.backends.postgresql.base
On 10/17/06, Mario Gonzalez ( mario__ ) <[EMAIL PROTECTED]> wrote: On 17/10/06, Rafael SDM Sierra <[EMAIL PROTECTED]> wrote:> ps2.: I need this a lot becouse I'm using FreeBSD, and it start only 50> connections simultaneously, but my system use but you can change that and default, postgres support 100connections (2 for superuser)You are right when you are working with Linux, but FreeBSD have a diferent kernel, to grow the maximum limit of connections on FreeBSD is needed to recompile the kernel (it's not so hard, but I want solve it with python :P) >--http://www.advogato.org/person/mgonzalez/ SDM UnderlinuxGarimpar.com--PEP-8Só existem 3 tipos de pessoas no mundo, as que sabem contar, e as que não sabem.CPFL - Compania Piratininga de FALTA de Luz (6 vezes em 5 dias!!) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: Call for testing: New setup.py
I missed the previous discussion, but I'm not pleased with this change. The developer version of Django is made available only via Subversion, so the requirement for internet access at install is hardly a disadvantage. Django is, after all, a web framework! The best way to install development Django on a Windows system has been to use the setuptools-provided command: setup.py develop With setuptools, this command copies nothing to site-packages except a setuptools-based link to the Django checkout, and Django is easily kept up to date with svn up. SInce Windows has no built-in linking, this setuptools-based linking is quite useful, and especially for newbies! This same installation approach has in my experience worked worked equally well on linux. (That this approach has not been mentioned at the front of the tutorial is an issue with the tutorial, not with setuptools. I first discovered it in the comments section for tutorial 1.) On Oct 16, 5:03 pm, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote: > Hi all, > > I've refactored Django's setup.py so that it uses the plain Python > distutils installation method rather than ez_setup/setuptools. This > means it no longer requires an Internet connection to install Django. > Hooray! > > But I have only tested this on Linux, so I'd appreciate it if folks > could test out the command "python setup.py install" on various > different platforms. Just grab the SVN version of Django and try > installing it using "python setup.py install". > > For the record, we previously discussed this on django-developers here: > > http://groups.google.com/group/django-developers/browse_thread/thread... > > The "straw that broke the camel's back," in this case, happened this > weekend when I was doing a Django tutorial in Boston and encountered > two people who'd had problems installing Django due to a setuptools > problem that was out of our control. (Namely, it was due to the fact > that Python 2.5's version of setuptools required a certain version of > ez_setup, or vice versa, or some other peculiar problem like that, > which was out of our control.) > > There was something about seeing this problems in real life, with > face-to-face conversations with real Django users, that finally put me > over the edge. > > Adrian > > -- > Adrian Holovaty > holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: Re: Call for testing: New setup.py
On 10/17/06, sbain <[EMAIL PROTECTED]> wrote: > The developer version of Django is made available only via Subversion, > so the requirement for internet access at install is hardly a > disadvantage. Django is, after all, a web framework! It is, but the setuptools requirement of an active internet connection makes it *extremely* difficult to use setuptools for things like automated installs on multiple machines -- it's not uncommon for servers to be installed, or mostly installed, while totally offline or when connected only to a private backplane. With setuptools that just wasn't possible. > With setuptools, this command copies nothing to site-packages except a > setuptools-based link to the Django checkout, and Django is easily kept > up to date with svn up. SInce Windows has no built-in linking, this > setuptools-based linking is quite useful, and especially for newbies! It's a tradeoff, though, because setuptools seems to be extremely brittle -- even minor changes in the easy_install/setuptools chain can apparently break the entire system, and that's much, much worse. In the long run, I think this change is for the best; issues with easy upgrades of SVN checkouts can be worked around, but not being installable on disconnected machines, or not being installable at all for a while whenever the easy_install stuff changes upstream, are much more severe and much harder to work around. -- "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 developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: Call for testing: New setup.py
Is there any reason to use either setuptools or distutils if one is doing an automated install of Django? Isn't it just copy or link the django directory to the Python path, copy django-admin.py to an executable path, and you are pretty much done? How would one now recommend that a new Windows developer install Django in a such a way as to facilitate keeping his Django updated to the trunk? The easiest to explain approach that I know about would be to ignore Django's setup.py. Instead install setuptools, manually create a Django.eggs-link file in site-packages, and then copy django-admin.py to the Python scripts directory. There are other ways - mostly involving access to Windows' painful UI for creating persistent environment variables - but they are not easier to explain or perform than the technique I just described Thus this change seems like a regression in the ease of a best-practices installation for new developers on Windows. And in defense of Phillip Eby's very laudable efforts, I suspect that the vast majority of all issues with the setuptools install would have been resolved by simply changing the instructions to: 1) First download and run the latest ez_setup.py 2 Checkout Django trunk 2) Then run python setup.py develop And users on all platforms would have then had a Django that is easily updated by svn up. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
