Re: Pre-validation form data processing step
Mikhail Gusarov wrote: > Hello, > > [accidentally posted in django-users first, please comment in > django-developers] > > I'd like to propose the following change to Model interface: optional > step to fixup the data got from the form before validation. This may > easily be done in custom views, but there is no proper way to do it in > admin interface. This fixup should operate on whole form data, exactly > as validation does. > > Example application may be the custom slug generation (filling slug > from the title if no explicit slug provided): > > > class AutopopulatedSlugField(models.SlugField): > def __init__() ... > > def fixup(self, field_name, all_data): > if all_data[field_name] == "": > all_data[field_name] = utils.urlify(all_data[self.populate_from]) > > class Entry(models.Model): > headline = models.CharField(maxlength = 512) > slug = models.AutopopulatedSlugField(populate_from='headline') > > class Admin: pass > > > AFAIU, changes to the codebase will be minimal (slight change of Model > class and additional no-op Field class operation). Is it worth to > implement it by myself and post in ticket? > > -- > JID: [EMAIL PROTECTED] I would do something like this. from django.db import models from django.dispatch import dispatcher from django.db.models import signals from django.utils import urlify class AutopopulatedSlugField(models.SlugField): def __init__(self, *args, **kwargs): models.SlugField.__init__(self, *args, **kwargs) def contribute_to_class(self, cls, , name): super(AutopopulatedSlugField, self).contribute_to_class(cls, name) dispatcher.connect(self.prepopulate_field, signals.pre_save, sender=cls) def prepopulate_field(self, instance): prepopulate = '' for field in self.prepopulate_from: prepopulate = '%s %s' % (prepopulate,getattr(instance, field)) setattr(instance, self.attname, urlify(prepopulate)) --~--~-~--~~~---~--~~ 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: Django - Oracle status?
Tom Zellman wrote: > I know one of the setbacks for some of the core developers/committers is > that they don't have an Oracle license to test with. The database I use at > work is located on a Solaris machine, and I'm stuck doing development on a > Windows hard-drive-encrypted laptop... so I use the Oracle InstantClient > (along with the cx_Oracle module). > http://www.oracle.com/technology/tech/oci/instantclient/index.html > In addition, I have used the Oracle Lite database for testing on my laptop: > http://www.oracle.com/technology/products/lite/index.html The express edition (free of charge for DB up to 4GB) should be your target for testing: http://www.oracle.com/technology/products/database/xe/index.html The Lite's engine AFAIK is and embedded version of Oracle that doesn't share the same code with the others. Lorenzo --~--~-~--~~~---~--~~ 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: bump: give Gabor (or somebody else) a unicode branch in svn
James Bennett wrote: > On 10/13/06, Jay Parlar <[EMAIL PROTECTED]> wrote: > > I know it's off-topic, but do you have any thoughts as to which > > branch? > > Based on my sporadic glances, I'd agree with you that row-level perms > and multi-db both look like good candidates to be finalized and > merged. I've been away for a bit (moving, limited access), so multi-db hasn't gotten a trunk merge in a few weeks. And at last update, only the postgres backend was passing all tests. SQLite still has problems with the test client snuffing out the in-memory db, mysql has problems because some of the multi-db-specific tests are looking for postgres quoting style in the generated sql, and I don't have access to any other backends to test with. I may be able to make time this week to merge up to trunk latest, but I can't guarantee that. The point is, though I hope multi-db will be merge worthy sometime soon, as of today I don't think it is. Sorry. 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 -~--~~~~--~~--~--~---
Potential bug in django.core.handlers.modpython ?
Hi,
I noticed an inconsistency between the request META information in the
modpython handler versus the base handler.
I'm opening the URL http://web/data/pos/ which goes through two URL
conf's:
The default urls.py for the application:
(r'^data/', include('pfweb.core.urls')),
And the urls.py for the 'core' app:
(r'^pos/$', 'pfweb.core.views.list_positions'),
But under mod_python, request.META['PATH_INFO'] is '/pos/' while in the
development server its '/data/pos/' (which I think is right).
I'm using the PATH_INFO as a base for my next/previous links so they
aren't working in production (under apache).
Shouldn't I be able to see the full path of the URL somehow under
mod_python? (Maybe there is a better way than I'm trying).
I'm not sure what's right so I thought I'd post a question here before
submitting a ticket.
Thanks,
-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: Potential bug in django.core.handlers.modpython ?
On 10/16/06 20:13, DavidA wrote:
> Hi,
>
> I noticed an inconsistency between the request META information in the
> modpython handler versus the base handler.
>
> I'm opening the URL http://web/data/pos/ which goes through two URL
> conf's:
>
> The default urls.py for the application:
> (r'^data/', include('pfweb.core.urls')),
>
> And the urls.py for the 'core' app:
> (r'^pos/$', 'pfweb.core.views.list_positions'),
>
> But under mod_python, request.META['PATH_INFO'] is '/pos/' while in the
> development server its '/data/pos/' (which I think is right).
>
> I'm using the PATH_INFO as a base for my next/previous links so they
> aren't working in production (under apache).
>
> Shouldn't I be able to see the full path of the URL somehow under
> mod_python? (Maybe there is a better way than I'm trying).
>
> I'm not sure what's right so I thought I'd post a question here before
> submitting a ticket.
>
Have you got a folder/file named 'data' in your apaches document root?
If so, try nuking or renaming it.
--~--~-~--~~~---~--~~
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: Potential bug in django.core.handlers.modpython ?
Steven Armstrong wrote: > Have you got a folder/file named 'data' in your apaches document root? > If so, try nuking or renaming it. No. And no virtual directories or aliases named 'data' either, nor a file or folder named 'data' in my django project directory. Note that the page URL is working (http://web/data/pos/) correctly under both Apache and the development server. Its just that I can't generate the correct URL for my next/prev links under Apache because that path is not correct. -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 -~--~~~~--~~--~--~---
Database race conditions when using multiple processes
Hello,
I was recently using the get_or_create method and noticed that it added
an entry twice into my database in very rare cases, because it
complained later that "get() returned more than one ___ -- it returned
2!". This problem didn't occur when using the development server.
My question is: Is there a way to avoid these race conditions by e.g.
locking the database? How can I do that?
This is my setup:
- Django (SVN) running with "python manage.py runfcgi method=prefork"
(there are 6 processes running)
- Lighttpd
- SQLite
To prove the race condition, I used the following model:
class Test(models.Model):
str = models.CharField(blank=True, null=True, maxlength=100)
The relevant part of my urls.conf is:
# Testing
(r'^test/$', 'test.main'),
(r'^test/process/$', 'test.process'),
And here's the view:
--- CUT HERE ---
from django.http import HttpResponse
import models
from json import load
def main(request):
return HttpResponse("""
http://prototype.conio.net/dist/prototype-1.4.0.js";
type="text/javascript">
http://www.json.org/json.js";
type="text/javascript">
function send_request(callback, text)
{
new Ajax.Request('process/' /* URL */, {
postBody:'text='+encodeURIComponent(text),
onComplete:callback
});
}
function debug(str)
{
var date = new Date();
str = date.toTimeString().substr(0, 8)+' '+str+'
';
$('debug').innerHTML = str+$('debug').innerHTML;
}
function cb(req)
{
if (req.status == 200)
debug('Received response: '+req.responseText);
else
debug('error '+req.status+' '+req.responseText);
}
function clicked()
{
send_request(cb, $('text').value);
send_request(cb, $('text').value);
send_request(cb, $('text').value);
send_request(cb, $('text').value);
send_request(cb, $('text').value);
send_request(cb, $('text').value);
send_request(cb, $('text').value);
send_request(cb, $('text').value);
send_request(cb, $('text').value);
send_request(cb, $('text').value);
}
test
""")
def process(request):
if request.POST.get('text'):
t =
models.Test.objects.get_or_create(str=request.POST.get('text'))[0]
return HttpResponse('%s %s' % (request.POST.get('text'), t.id))
else:
return HttpResponse('Missing argument')
--- CUT HERE ---
When I play around with it, I sometimes get this debug output followed
by an AssertionError (notice the different IDs):
20:07:41 Received response: blah 21
20:07:41 Received response: blah 19
20:07:41 Received response: blah 20
20:07:41 Received response: blah 19
I know that in this specific case it can be enforced at database level
using the unique and unique_together properties, but how would you
handle e.g. this scenario?
1 def transfer_money(from_id, to_id, amount)
2from = models.BankAccount.objects.get(id=from_id)
3to = models.BankAccount.objects.get(id=to_id)
4from.balance -= amount
5to.balance += amount
6from.save()
7to.save()
What, if two Django processes transfer money from account A to account
B simultaneously?
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: Database race conditions when using multiple processes
Thomas Steinacher wrote: > I know that in this specific case it can be enforced at database level > using the unique and unique_together properties, but how would you > handle e.g. this scenario? > > 1 def transfer_money(from_id, to_id, amount) > 2from = models.BankAccount.objects.get(id=from_id) > 3to = models.BankAccount.objects.get(id=to_id) > 4from.balance -= amount > 5to.balance += amount > 6from.save() > 7to.save() > > What, if two Django processes transfer money from account A to account > B simultaneously? > these situations are (afaik) handled using transactionssimply start a transaction at the beginning, and commit/rollback at the end... gabor --~--~-~--~~~---~--~~ 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
On 10/16/06, Thomas Steinacher <[EMAIL PROTECTED]> wrote: > This is my setup: > > - Django (SVN) running with "python manage.py runfcgi method=prefork" > (there are 6 processes running) > - Lighttpd > - SQLite SQLite is *not* something to be using if proper locking and safe concurrent access will be important; SQLite's own docs point out a couple of cases where its locking just won't work, and they recommend moving to a client-server RDBMS like PostgreSQL or MySQL if safe concurrent access is a major issue -- those systems implement much finer-grained control, for example, where SQLite has to lock the entire DB file for writing. -- "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
On 16/10/06, James Bennett <[EMAIL PROTECTED]> wrote: > > SQLite is *not* something to be using if proper locking and safe > concurrent access will be important; SQLite's own docs point out a > couple of cases where its locking just won't work, and they recommend > moving to a client-server RDBMS like PostgreSQL or MySQL if safe you're right, Postgres don't do a block in the entire db but if two proccess want to write, they going to do it anyway, which one finish first? it doesn't matter. So, IMVHO, that isn't the problem. > -- 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: Potential bug in django.core.handlers.modpython ?
DavidA wrote: > But under mod_python, request.META['PATH_INFO'] is '/pos/' while in the > development server its '/data/pos/' (which I think is right). I notice the same problem here. Running Apache 2.0.58-r2 and mod_python 3.1.4-r1 on a gentoo box. for instance : I'm not using this variable right now in my projects, but I think you are right there is something weird here . Regards, xav --~--~-~--~~~---~--~~ 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: Potential bug in django.core.handlers.modpython ?
On 10/16/06, DavidA <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I noticed an inconsistency between the request META information in the
> modpython handler versus the base handler.
>
> I'm opening the URL http://web/data/pos/ which goes through two URL
> conf's:
>
> The default urls.py for the application:
> (r'^data/', include('pfweb.core.urls')),
>
> And the urls.py for the 'core' app:
> (r'^pos/$', 'pfweb.core.views.list_positions'),
>
> But under mod_python, request.META['PATH_INFO'] is '/pos/' while in the
> development server its '/data/pos/' (which I think is right).
>
> I'm using the PATH_INFO as a base for my next/previous links so they
> aren't working in production (under apache).
>
> Shouldn't I be able to see the full path of the URL somehow under
> mod_python? (Maybe there is a better way than I'm trying).
>
> I'm not sure what's right so I thought I'd post a question here before
> submitting a ticket.
>
> Thanks,
> -Dave
My guess is the problem lies in your Apache settings. Post a copy of
your mod-python settings and we'll see what we come up with.
--
Waylan Limberg
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
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
On Oct 16, 2006, at 8:46 PM, gabor wrote: > > What, if two Django processes transfer money from account A to account > > B simultaneously? > > these situations are (afaik) handled using transactionssimply start > a transaction at the beginning, and commit/rollback at the end... I already included "django.middleware.transaction.TransactionMiddleware" in my MIDDLEWARE_CLASSES (as described on http://www.djangoproject.com/documentation/transactions/#tying-transactions-to-http-requests) and it didn't help. 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: Database race conditions when using multiple processes
Thomas Steinacher wrote: > On Oct 16, 2006, at 8:46 PM, gabor wrote: >>> What, if two Django processes transfer money from account A to account >>> B simultaneously? >> these situations are (afaik) handled using transactionssimply start >> a transaction at the beginning, and commit/rollback at the end... > > I already included > "django.middleware.transaction.TransactionMiddleware" in my > MIDDLEWARE_CLASSES (as described on > http://www.djangoproject.com/documentation/transactions/#tying-transactions-to-http-requests) > and it didn't help. > you mean it did not help with the money-transfer code? gabor --~--~-~--~~~---~--~~ 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: Potential bug in django.core.handlers.modpython ?
Waylan Limberg wrote: > My guess is the problem lies in your Apache settings. Post a copy of > your mod-python settings and we'll see what we come up with. Here you go (C:/pf/src/pfweb is the Django project directory): NameVirtualHost * ServerName web DocumentRoot "C:/pf/src/pfweb" SetHandler mod_python PythonHandler django.core.handlers.modpython SetEnv DJANGO_SETTINGS_MODULE pfweb.settings PythonInterpreter admin SetHandler mod_python PythonHandler django.core.handlers.modpython SetEnv DJANGO_SETTINGS_MODULE pfweb.settings PythonInterpreter apps Alias /admin-media/ "C:/Python24/Lib/site-packages/Django-0.95-py2.4.egg/django/contrib/admin/media/" SetHandler none --~--~-~--~~~---~--~~ 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
gabor wrote: > Thomas Steinacher wrote: > > I already included > > "django.middleware.transaction.TransactionMiddleware" in my > > MIDDLEWARE_CLASSES (as described on > > http://www.djangoproject.com/documentation/transactions/#tying-transactions-to-http-requests) > > and it didn't help. > > > > you mean it did not help with the money-transfer code? > > gabor It did not help with the code I posted that was using get_or_create(), because I didn't use unique_together... I don't think it would help with the money-transfer code. The documentation says: "It works like this: When a request starts, Django starts a transaction. If the response is produced without problems, Django commits any pending transactions. If the view function produces an exception, Django rolls back any pending transactions." The problem is that the code doesn't produce an exception, so Django will not roll back anything... 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: Django - Oracle status?
Thanks, Tom. (This is Matt, following up on the dev list.) The issues we're seeing with your latest Oracle patch on top of Django 0.95 do mostly pertain to a syncdb. Specifically, it looks as though Oracle's 30-character limit on most identifiers is not taken into account, so some constraint definitions fail. This is a shame, since Django appears to emit a good schema with integrity otherwise. The other problem (which I provided a hacked-up "solution" for in a comment on bug #1990) is that Oracle barfs on the optional AS keyword in some cases. Omitting "AS" fixes this, but requires another "if settings.DATABASE == 'oracle'" clause, which I'm guessing gets us no closer to being included in the source tree. Another problem we're seeing once up and running is some queries have two named args, both named ":arg" in the SQL, which causes the first bind parameter to be used twice. Anyway, I'll try to document these problems more cleanly. We would like to get into helping with this. I'll keep watching this list and keep communicating--we can all get it done together. --~--~-~--~~~---~--~~ 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 wrote: > gabor wrote: >> Thomas Steinacher wrote: >>> I already included >>> "django.middleware.transaction.TransactionMiddleware" in my >>> MIDDLEWARE_CLASSES (as described on >>> http://www.djangoproject.com/documentation/transactions/#tying-transactions-to-http-requests) >>> and it didn't help. >>> >> you mean it did not help with the money-transfer code? >> >> gabor > > It did not help with the code I posted that was using get_or_create(), > because I didn't use unique_together... I don't think it would help > with the money-transfer code. > > The documentation says: > > "It works like this: When a request starts, Django starts a > transaction. If the response is produced without problems, Django > commits any pending transactions. If the view function produces an > exception, Django rolls back any pending transactions." > > The problem is that the code doesn't produce an exception, so Django > will not roll back anything... > ok, then maybe this is a misunderstanding, so let's restart the discussion: what is your question? :) gabor --~--~-~--~~~---~--~~ 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: Potential bug in django.core.handlers.modpython ?
On 10/16/06 20:27, DavidA wrote: > > Steven Armstrong wrote: >> Have you got a folder/file named 'data' in your apaches document root? >> If so, try nuking or renaming it. > > No. And no virtual directories or aliases named 'data' either, nor a > file or folder named 'data' in my django project directory. > > Note that the page URL is working (http://web/data/pos/) correctly > under both Apache and the development server. Its just that I can't > generate the correct URL for my next/prev links under Apache because > that path is not correct. > > -Dave > Pitty that didn't work. I've had similar problems with mod_python and in my case it was apache being confused because of a folder with the same name in document root. After renaming the folder everything was fine. Anyway it seems like this is a common problem with mod_python [1], [2]. The trac devs have also bumped into this. They solved it by explicitly passing the base url with a PythonOption [4]. Same as the MoinMoin devs [3]. Googling for 'mod_python path_info' turns up loads of similiar questions/problems/solutions. Probably a mechanism like that [5] could/should be built into djangos mod_python handler. [1] http://mail.mems-exchange.org/durusmail/quixote-users/3250/ [2] http://www.modpython.org/pipermail/mod_python/2003-July/013948.html [3] http://moinmoin.wikiwikiweb.de/HelpOnInstalling/ApacheWithModPython [4] http://trac.edgewall.org/ticket/552 [5] http://trac.edgewall.org/changeset/797 --~--~-~--~~~---~--~~ 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/16/06, Thomas Steinacher <[EMAIL PROTECTED]> wrote: > It did not help with the code I posted that was using get_or_create(), > because I didn't use unique_together... I don't think it would help > with the money-transfer code. This is a tricky problem, not least because each of the DBs we support has a slightly different transaction setup. If it were me doing this, I'd isolate the critical areas of the code where it's possible for a race condition to occur, and manually execute the appropriate statements to secure whatever I was doing. For example, if I were using PostgreSQL, I'd use the 'commit_manually' decorator on my view, and manually set the transaction isolation level to SERIALIZABLE before doing anything else. For truly critical operations, I'd probably just go ahead and grab an exclusive lock on whatever I needed, and force other transactions to wait. Because the requirements of different use cases vary so much, and because no two DBs handle it exactly the same way, I don't think we could ever have a successful automated solution. -- "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 wrote: > For truly critical > operations, I'd probably just go ahead and grab an exclusive lock on > whatever I needed, and force other transactions to wait. how would you that? 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")? or would you rather do it with something completely different? a temporary lock-file in a temp-directory perhaps? gabor --~--~-~--~~~---~--~~ 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/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 -- "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 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
>
thanks a lot
(and again something that would be relatively easy to find with a
google("postgresql lock"). next time i will do the googling before
asking, i promise (/me makes a mental note of it AGAINNN) :)
gabor
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Call for testing: New setup.py
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/af002765821b5e57/27a927caaee9ad78 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: Call for testing: New setup.py
On 10/16/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > 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". Works fine with OS X 10.4.8 (PPC) + python 2.4.3 via darwinports. Joseph --~--~-~--~~~---~--~~ 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
On 10/16/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > 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". Python 2.5 with OS X 10.4.8 (Intel) seems fine. I'll try Python 2.4 with OS X 10.3.9 when I get home. Jay P. --~--~-~--~~~---~--~~ 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
Didn't work for me on Windows XP with python 2.4.3...what I got is this: > C:\Documents and Settings\floguy\Desktop\newdjango>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 I checked, and django-admin.py did get moved into the scripts directory, but I couldn't find any of the other files in any directory in or under C:\Python24. --~--~-~--~~~---~--~~ 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
WinXP, Python 2.43 - worked OK for me. Dropped all the goodies into c:\python24\lib\site-packages\django...-joeOn 10/16/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Didn't work for me on Windows XP with python 2.4.3...what I got isthis:> C:\Documents and Settings\floguy\Desktop\newdjango>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_dataI checked, and django-admin.py did get moved into the scriptsdirectory, but I couldn't find any of the other files in any directory in or under C:\Python24. --~--~-~--~~~---~--~~ 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
OS X 10.3.9 with Python 2.4.3 seems fine. Jay P. --~--~-~--~~~---~--~~ 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: Django - Oracle status?
On Mon, 2006-10-16 at 20:11 +, ogghead wrote: > Thanks, Tom. (This is Matt, following up on the dev list.) > > The issues we're seeing with your latest Oracle patch on top of Django > 0.95 do mostly pertain to a syncdb. Specifically, it looks as though > Oracle's 30-character limit on most identifiers is not taken into > account, so some constraint definitions fail. This is a shame, since > Django appears to emit a good schema with integrity otherwise. We need to make everything shorter and move it into the database-specific backends. I think we have reasonable consensus amongst those who care about this that it's time to stop trying to be descriptive and start being functional. It's a matter of just doing the work here, rather than trying to work out the solution. > The other problem (which I provided a hacked-up "solution" for in a > comment on bug #1990) is that Oracle barfs on the optional AS keyword > in some cases. Omitting "AS" fixes this, but requires another "if > settings.DATABASE == 'oracle'" clause, which I'm guessing gets us no > closer to being included in the source tree. The good news here is that in "from" clauses, MySQL, PostgreSQL and SQLite all allow "as" to be optional, so we can omit it across the board. No need for a case-by-case analysis (and now somebody will say that MS-SQL requires it). I cannot remember the different variations for using "as" in aliased output columns in the "select" clause, but I do know that it is required in PostgreSQL. Fortunately (or rather, accidentally), Django does not use aliases on output columns at the moment, so it's a moot point. > Another problem we're seeing once up and running is some queries have > two named args, both named ":arg" in the SQL, which causes the first > bind parameter to be used twice. > > Anyway, I'll try to document these problems more cleanly. We would > like to get into helping with this. I'll keep watching this list and > keep communicating--we can all get it done together. Clear documentation on where the current problems are and what constraints we are working within would be a great help. Not just for fixing the immediate problems, but for documenting *why* we have made some of these choices for the benefit of future maintenance. All help there will be greatly appreciated. Regards, Malcolm --~--~-~--~~~---~--~~ 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: bump: give Gabor (or somebody else) a unicode branch in svn
On Mon, 2006-10-16 at 14:53 +, JP wrote: > James Bennett wrote: > > On 10/13/06, Jay Parlar <[EMAIL PROTECTED]> wrote: > > > I know it's off-topic, but do you have any thoughts as to which > > > branch? > > > > Based on my sporadic glances, I'd agree with you that row-level perms > > and multi-db both look like good candidates to be finalized and > > merged. > > I've been away for a bit (moving, limited access), so multi-db hasn't > gotten a trunk merge in a few weeks. And at last update, only the > postgres backend was passing all tests. SQLite still has problems with > the test client snuffing out the in-memory db, mysql has problems > because some of the multi-db-specific tests are looking for postgres > quoting style in the generated sql, and I don't have access to any > other backends to test with. > > I may be able to make time this week to merge up to trunk latest, but I > can't guarantee that. > > The point is, though I hope multi-db will be merge worthy sometime > soon, as of today I don't think it is. Sorry. 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. I'm trying to recover my sanity and catch up on obligations, so I would like to get to it by first week in November. Regards, Malcolm --~--~-~--~~~---~--~~ 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 Adrian, On 17/10/06, 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". In the buildbot slave I'm setting up for pybots.org I get a problem with the old setuptools version of django-admin.py not being replaced by the real one. My setup has a temporary python2.5 build in /tmp/python-buildbot/local/bin/python with django trunk r3905 (pre-setuptools removal) installed in /tmp/python-buildbot/local/lib/python2.5/site-packages. If I do a '/tmp/python-buildbot/local/bin/python setup.py install' with the latest trunk it doesn't replace the /tmp/python-buildbot/local/bin/django-admin.py script or remove the old django egg. If I then go and remove the old egg from site-packages django-admin.py breaks. If I do a completely clean install without a previous setuptools version of django present then it works fine. This is on a Solaris 10 system with python 2.5. > > For the record, we previously discussed this on django-developers here: > > http://groups.google.com/group/django-developers/browse_thread/thread/af002765821b5e57/27a927caaee9ad78 > > 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 -~--~~~~--~~--~--~---
feature request: Bonjour support
One thing I really love about TurboGears, that would make developing in Django that much sweeter, would be Bonjour support. It looks like a pretty trivial piece of code in TurboGears's startup.py file, but I'm extremely new to Django and wouldn't know where to start adding it myself. --~--~-~--~~~---~--~~ 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: bump: give Gabor (or somebody else) a unicode branch in svn
On Tue, 2006-10-17 at 09:54 +1000, Malcolm Tredinnick wrote: [...] > And my apologies to use, JP: Hmm ... should have been "my apologies to *you*...". One day I really will have to sit down and learn this English language thing (and maybe take some kind of "how to type" class). Malcolm --~--~-~--~~~---~--~~ 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
You're probably going to have to elaborate a bit further. What exactly is "bonjour support" ? Does it have anything to do with the technology formerly known as Rendezvous in OS X (more commonly known as ZeroConf)? -- Clint Ecker | STONE WARD 440 N. Wells, Suite 750, Chicago, IL 60610 Boston | [ Chicago ] | Little Rock www.stoneward.com On 10/16/06, evariste <[EMAIL PROTECTED]> wrote: > > One thing I really love about TurboGears, that would make developing in > Django that much sweeter, would be Bonjour support. It looks like a > pretty trivial piece of code in TurboGears's startup.py file, but I'm > extremely new to Django and wouldn't know where to start adding it > myself. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
django build slave
Hi, I've now got a Solaris 10 sparc buildbot slave up and running at: http://www.python.org/dev/buildbot/community/all/ It is running the django trunk tests against both python 2.5 and python trunk using a sqlite3 memory database. Are any of the core developers interested in receiving test failure emails? regards matthew --~--~-~--~~~---~--~~ 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
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 -~--~~~~--~~--~--~---
7 Habits of Highly effective Person By Stephen Covey: Audio Books
Links given for first two parts of audio Books in Audio Book section. Balance parts will be shortly given-- With warm regardsP K KothariDownload PowerPoint Presentation files: http://powerpoint-presentation.blogspot.comDownload eBooks: http://ebook-share.blogspot. Download Audio books in MP3: http://audiobook-share.blogspot.comDownload Management Articles: http://management-article.blogspot.comDownload Collection Articles: http://collection-share.blogspot.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 -~--~~~~--~~--~--~---
