Re: 1.7a1 - Migration syntax error
On Wednesday 05 February 2014 04:49 AM, Russell Keith-Magee wrote: This is the 0001_initial migration - did you manually write or update this migration, or is this code entirely automatically generated? If it's manually written or edited, then fix what you wrote :-) If it's the result of automated output, then it appears you've found a bug. I'm guessing it's a problem with the serialisation of datetimes as defaults. If you can open a ticket describing the model that caused the problem, that would be very helpful. Hi Russ, the file was generated by makemigrations. I have raised a ticket here - https://code.djangoproject.com/ticket/21954 Thanks, -- Pradip P Caulagi -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/52F1D61E.5030900%40gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Do I need an API?
I think it is dangerous to let users edit the HTML directly, in my opinion you should let them edit the content and maybe some formating On Feb 5, 2014 12:27 AM, "m1chael" wrote: > I think the point is: it's difficult for old-school tech people to > work with Django because there is a learning curve, and it's hard to > mimic exactly what they are used to, and it's difficult to persuade > them this is the right way to do things. > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-users+unsubscr...@googlegroups.com. > To post to this group, send email to django-users@googlegroups.com. > Visit this group at http://groups.google.com/group/django-users. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-users/CAAuoY6NHofU5tOffNwxhQtCithm_T6F3__gkd%2B%3Dk%2Bbn1HNu%2B8A%40mail.gmail.com > . > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFWa6tLTCzQA4jAu2p4kraUFy_5%2B6ownHnxVZxDGcF-wvJq7iw%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Model field's verbose_name from database?
Correction: Values should also be strings
mapping = {
'My Name': 'first_name',
'Surname': 'last_name',
'Personal Email': 'email'
}
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/d9406eda-388d-41d2-a488-c39862e6ea0f%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Model field's verbose_name from database?
Why not use dictionary to Map user-level names to database-fields
mapping = {
'My Name': first_name,
'Surname': last_name,
'Personal Email': email
}
u = User.objects.get(pk=1)
key = 'My Name'
try:
val = getattr(u, mapping[key])
except AttributeError:
val = ''
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/1ed11234-acfb-4d7a-b67e-631e583dc51b%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Many-to-many with inlineformset_factory - row for each possible value?
Hi all,
New to Django, I've scoured the Web to see if there's an answer to this
particular problem - wondering if anyone could assist:
I have two models related many-to-many through a third, e.g.
class Site(models.Model):
id = models.PositiveSmallIntegerField(primary_key=True)
name = models.CharField(max_length=80)
items = models.ManyToManyField(Item, through="Allocation")
class Item(models.Model):
name = models.CharField(max_length=80)
class Allocation(models.Model):
site = models.ForeignKey(Site)
item = models.ForeignKey(Item)
qty = models.PositiveSmallIntegerField()
and I'm trying to make a view/form for Allocation (for one particular Site
- it takes the site ID as an argument to the view).
I've managed to create an inline formset with these lines in my view:
def allocations_page(request, site_id):
site = Site.objects.get(id=site_id)
AllocationSubForm = inlineformset_factory(Site, Site.items.through,
form=AllocationForm)
aform = AllocationSubForm()
return render(request, 'allocations.html', { 'subform': aform})
Which seems to work, in that it it shows 3 blank rows - each row prompts
the user to select an Item from a dropdown and fill the qty in.
However, rather than having this scenario, I would much prefer to have a
row for every Item in the Item table, regardless of whether an Allocation
exists for it (show a qty of blank or 0 if there's no entry in Allocation
yet), and simply have the name attribute as a label to the "qty" field. In
essence, Item left joined to Site through Allocation.
Is this easily achievable?
Thanks,
Miles
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/20234e55-841d-4ec5-9b59-d31f9229dda7%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Do I need an API?
I would second the idea for a full cms to solve your problem. Whether django, our some other cms. Mark On Feb 4, 2014 3:27 PM, "m1chael" wrote: > I think the point is: it's difficult for old-school tech people to > work with Django because there is a learning curve, and it's hard to > mimic exactly what they are used to, and it's difficult to persuade > them this is the right way to do things. > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-users+unsubscr...@googlegroups.com. > To post to this group, send email to django-users@googlegroups.com. > Visit this group at http://groups.google.com/group/django-users. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-users/CAAuoY6NHofU5tOffNwxhQtCithm_T6F3__gkd%2B%3Dk%2Bbn1HNu%2B8A%40mail.gmail.com > . > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAEqej2MHDRY1TEcmLbczK21k%3DbGuWHX%3D9WQY45zNeT4Q8uKtug%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: 1.7a1 - Migration syntax error
Hi Pradip,
On Tue, Feb 4, 2014 at 5:18 PM, Pradip Caulagi wrote:
> I am using the following (simplified) model that doesn't migrate using the
> new migrations in Django 1.7a1 -
>
> ...
>
File "/tmp/bar/blog/migrations/0001_initial.py", line 17
> ('created', models.DateTimeField(default=datetime.datetime(2014, 2,
> 4, 9, 15, 59, 685251, tzinfo=))),
>
> ^
> SyntaxError: invalid syntax
> $
> $
>
> What am I missing? I know that we can have use auto_now for the
> DateTimeField but I want the value to be shown populated with current
> datetime that can be overridden by the user, if they want.
>
A Django migration file is just a Python file. The error you're seeing is a
Python error - the code you've entered, at line 17, at the point where the
caret is pointing, isn't valid syntax.
Specifically - "tzinfo=" isn't legal Python.
This is the 0001_initial migration - did you manually write or update this
migration, or is this code entirely automatically generated? If it's
manually written or edited, then fix what you wrote :-) If it's the result
of automated output, then it appears you've found a bug. I'm guessing it's
a problem with the serialisation of datetimes as defaults. If you can open
a ticket describing the model that caused the problem, that would be very
helpful.
Yours,
Russ Magee %-)
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/CAJxq849oRZqFUnbr48fTLOO_CfOZn3vXGj23%2B66E0TWuu1KZ9g%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Do I need an API?
I'm not clear on your question. I can't tell if you are wanting to allow them to edit the site layout (templates) or content that happens to contain html? Either way, you might look into using the Ace javascript based code editor http://ace.c9.io/ If you are talking about letting them modify the templates, what we do is have a directory for each templates that is at the top of the template loader order, so all templates can be overridden. A kind of 'theme' folder that contains the files we want to allow admins to edit. It's fairly easy to walk that directory structure and give them a list of editable files, and then pull up a page with Ace to edit them. Things get a lot more complicated if you want to allow admins to override arbitrary app level templates, but it's possible too with some modified template loaders so you can track the source with regard to template resolution order. Changes still get saved to the override directory, so no changes are made to the module level templates and they can just delete the custom file to return to original. -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/3bdbe0a6-d68a-4c4e-ae41-1235626f0ad0%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Do I need an API?
I think the point is: it's difficult for old-school tech people to work with Django because there is a learning curve, and it's hard to mimic exactly what they are used to, and it's difficult to persuade them this is the right way to do things. -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAAuoY6NHofU5tOffNwxhQtCithm_T6F3__gkd%2B%3Dk%2Bbn1HNu%2B8A%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Opening up multiple database connections per request?
Thank you Russ. Your solution to define multiple database sources to a single database was very straightforward On Tuesday, January 21, 2014 4:11:43 PM UTC-8, Russell Keith-Magee wrote: > > Hi Jeff, > > Correct - Django has one database connection per request. > > If you want to open multiple connections, you're going to look into > Django's support for multiple databases. You're using django.db.connection; > this is really just shorthand for django.db.connections['default']. If you > define an 'other' database in your settings file, you can connect to > django.db.connections['other'] as well, using a separate connection. > > Although this was developed with the intention of accessing multiple > *different* database sources (e.g., a database master and a slave, or a > sharded database), there's no reason you can't have multiple connections to > the same database (in fact, this can be a handy way to test logic around > master/slave configurations without needing to set up a master/slave > database configuration). > > The simple approach to this requires pre-declaration of the number of > connections you want to have; if you're particularly ingenious, you might > be able to mess with the internals of the ConnectionManager object to > dynamically create extra connections at runtime based upon the definition > of your base database. However, this is undocumented API, so you're on your > own if you take this path. > > Yours, > Russ Magee %-) > > > On Wed, Jan 22, 2014 at 7:40 AM, jeff do >wrote: > >> Is it possible to open up multiple database connections inside of one >> request in Django? I am using Django 1.6 and Python3.3. >> >> In my use case, I have a web application that executes raw SQL against a >> data warehouse we have. For example, one page may require five different >> SQL queries to be executed to pull down all the datasets necessary to >> display as charts, tables, etc. >> >> Using only one database connection and executing the SQL queries >> synchronously is too slow, so I am trying to use threads (specifically the >> concurrent.futures package in stdlib) to run my queries asynchronously. In >> particular, I have code that looks like: >> >> >> >> from django.db import connection >> >> from concurrent.futures import ThreadPoolExecutor, as_completed >> >> def execute_query(sql): >> >>cursor = connection.cursor() >> >>… >> >>rows = cursor.fetchall() >> >> return rows >> >> def execute_queries_asynchronously(list_of_sql_queries): >> >> datasets = [] >> >> with ThreadPoolExecutor(max_workers=3) as executor: >> >> futures = [executor.submit(execute_query, query) for query in >> list_of_sql_queries] >> >> for future in as_completed(futures): >> >> datasets.append(future.result()) >> >> return datasets >> >> >> >> When I run the above code in shell, total execution time improves >> noticeably which is expected (about 2x-3x faster). However, when I put this >> code in my web application, I get an almost negligible performance gain, if >> any. It doesn’t seem like Django is opening up more DB connections. I’d >> like Django to open up a new connection or pull from the connection pool >> for every worker thread. Does the Django connection handler limit the >> number of available DB connections to a request to only one? >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to django-users...@googlegroups.com . >> To post to this group, send email to django...@googlegroups.com >> . >> Visit this group at http://groups.google.com/group/django-users. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-users/cb7ebe95-1565-4f4b-84cd-e25a36a7497a%40googlegroups.com >> . >> For more options, visit https://groups.google.com/groups/opt_out. >> > > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/602af76f-99aa-4826-8351-00fa88ca79a9%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Do I need an API?
Thanks for the responses, I have thought about a CMS and that's kind of what I thought I was building albeit a very small one. Mike, do you use heroku? I can't find a way to give ftp access to the templates, as I think its ethereal (not sure that's the right word!).. But I guess this means that an API is overkill? Thanks again! -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/7fe6e7de-a01e-4fa1-86d2-f2b8324f81ae%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: How to count the amount of objects in a django joined table?
This might be what you're looking for. One caveat, tho, the queryset
should be .ordered_by('user')
{% regroup object_list by user as user_list %}
{% for user in userlist_list %}
{{ user.user.id }} {{user.list|length}}
{% for asset in user.list %}
{{ asset.serial }}
{% endfor %}
{% endfor %}
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/3e573ccd-622f-4181-aa2c-6c8a353ec26e%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Model field's verbose_name from database?
Hi, I have a model with fields that allows the user to modify the user-facing names of these fields. Think "first name", "last name", "email", the user may prefer these be displayed as "given name", "surname", "email address". This is configured exactly once throughout the system. So in this example *all* instances of "first name" should instead be displayed as "given name". Is it possible have a model where "verbose_name" is not a static string, but instead comes from the database? Perhaps with some lazy loading trickery? I want to do something in the spirit of: first_name = models.CharField(..., verbose_name=lazy_load_name_from_db()) My hope is to eliminate the need to think about what to call this field when displayed to the user. Thanks, Jon -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CADhq2b6hoXB66hE2oWkhXe4TsvNmfWE%2Bw72dHj2ipkyYRGv1bw%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: ec2 using bitnami djangostack: application never loads; browser just hangs
Hi,
I'm sorry you are finding issues with the Bitnami image. I just saw
this, sorry if it is too late. Which version are you using? Can you
check if the django.conf file (apps/django/conf/django.conf) is
overwriting your /static alias? Also did you give permission to the
daemon user to read your project?
Best regards,
Victoria.
On Thu, Jan 23, 2014 at 4:49 AM, Dylan Bumford wrote:
> Thanks. I've checked apache's error_log, and it doesn't report anything
> unusual. The access_log reports about four hundred GET requests that look
> sort of like this:
>
> 10.73.205.233 - - [22/Jan/2014:18:07:34 -0500] "GET
> /img/ami-lower-container.png HTTP/1.1" 304 -
> 10.73.205.233 - - [22/Jan/2014:18:07:34 -0500] "GET /img/ami-list-item.png
> HTTP/1.1" 304 -
>
>
> The last two lines are:
>
> 201.249.174.162 - - [22/Jan/2014:18:09:19 -0500] "HEAD / HTTP/1.0" 200 -
> 120.192.101.153 - - [22/Jan/2014:19:21:28 -0500] "GET /manager/html
> HTTP/1.1" 404 210
>
>
> I don't know what other logs to check. When I run the app in DEBUG=True, I
> don't see any difference. If I introduce an artificial bug in
> /mysite/mysite/urls.py, it reports the bug through the Django debugging page
> (and also in error_log). But when I remove the bug, it's back to endless
> waiting. How can I tell if the request is making it to modwsgi or it's stuck
> in apache?
>
> Dylan
>
> On Wednesday, January 22, 2014 12:26:13 PM UTC-5, Andréas Kühne wrote:
>>
>> 1. Have you checked all of the access logs and error logs when the app is
>> started? Is your request getting served by modwsgi, or is it stuck in
>> apache?
>> 2. Start the application with DEBUG=True in settings, to see if you get
>> any information from the app.
>>
>> Thats where I'd start.
>>
>> Regards,
>>
>> Andréas Kühne
>>
>>
>> 2014/1/22 Dylan Bumford
>>>
>>> I used the Bitnami Djangostack AMI to set up a Django environment with
>>> apache2 and mod_wsgi on a free instance provided by Amazon's EC2. The django
>>> app is installed at /opt/bitnami/apps/django/django_projects/mysite,
>>> alongside the default Project application that comes with the stack. The app
>>> runs on my local computer on the development server without issue. When I
>>> transferred the app to the server, I ran the collectstatic script to copy
>>> all of the static files to mysite/static, and configured the server to serve
>>> STATIC_ROOT at STATIC_URL (settings and configuration details are reported
>>> below). As best I can make out, I've configured everything in accordance
>>> with the Django documentation and modwsgi documentation.
>>>
>>> When I point my browser to the server's public address, I see the bitnami
>>> startup page, but when I point to the subdirectory mapped to the
>>> application, the browser just hangs. It acts as if it's loading a website,
>>> spins the little wheel to tell you it's loading a website, and says 'Waiting
>>> for xx.xxx.xxx.xxx..." But nothing ever happens. There are no errors
>>> reported in /opt/bitnami/apache2/logs/error_log. But If I point instead to a
>>> random subdirectory that doesn't exist, I get a 404 page. If I point to the
>>> static subdirectory, I get a 403 Forbidden page. If I purposefully add a bug
>>> to any of the python code (in e.g. mysite/mysite/urls.py or
>>> mysite/myapp/views.py), I get a 500 Internal Server Error and a message in
>>> the error_log with the expected python stack trace.
>>>
>>> If anyone has any suggestions, I would obviously be very grateful. I'm
>>> pretty new to this.
>>>
>>> Here are the relevant parts of my configuration files.
>>>
>>>
>>> /opt/bitnami/apache2/conf/httpd.conf
>>>
>>> ServerRoot "/opt/bitnami/apache2"
>>> Listen 80
>>>
>>> User daemon
>>> Group daemon
>>>
>>> ServerName localhost:80
>>> DocumentRoot "/opt/bitnami/apache2/htdocs"
>>>
>>> Options Indexes FollowSymLinks
>>> AllowOverride None
>>>
>>> LoadModule wsgi_module modules/mod_wsgi.so
>>> WSGIPythonHome /opt/bitnami/python
>>> Include "/opt/bitnami/apps/django/conf/mysite.conf"
>>>
>>>
>>>
>>> /opt/bitnami/apps/django/conf/mysite.conf
>>>
>>> Alias /static "opt/bitnami/apps/django/django_projects/mysite/static"
>>>
>>>
>>> Order deny,allow
>>> Allow from all
>>>
>>>
>>> >> 'opt/bitnami/apps/django/lib/python2.7/site-packages/django/contrib/'>
>>>
>>> Order allow,deny
>>> Allow from all
>>>
>>> = 2.3>
>>> Require all granted
>>>
>>>
>>>
>>> WSGIScriptAlias /mysite "opt/bitnami/apps/django/scripts/mysite.wsgi"
>>> WSGIPythonPath 'opt/bitnami/apps/django/django_projects/mysite/'
>>>
>>>
>>>
>>> Order allow,deny
>>> Allow from all
>>>
>>> = 2.3>
>>> Require all granted
>>>
>>>
>>>
>>>
>>>
>>> /opt/bitnami/apps/django/scripts/mysite.wsgi
>>>
>>> import os, sys
>>>
>>> sys.path.append('/opt/bitnami/apps/django/lib/python2.7/site-packages/')
>>> sys.path.append('/opt/bitnami/apps/django/django_projects')
>>> sys.path.append('/opt/bitnami/apps/django/django_projects/mysite')
>>> os.environ['
Re: Django 1.6.1 not cooperating too well with Gevent
On Tuesday, February 4, 2014 11:15:26 AM UTC, André Cruz wrote: > One was blocked on: > File > "/servers/python-environments/discosite/local/lib/python2.7/site-packages/gevent/greenlet.py", > > line 327, in run# > result = self._run(*self.args, **self.kwargs)# > File > "/servers/python-environments/discosite/local/lib/python2.7/site-packages/django/http/response.py", > > line 308, in close# > signals.request_finished.send(sender=self._handler_class)# > File > "/servers/python-environments/discosite/local/lib/python2.7/site-packages/django/dispatch/dispatcher.py", > > line 184, in send# > for receiver in self._live_receivers(sender):# > File > "/servers/python-environments/discosite/local/lib/python2.7/site-packages/django/dispatch/dispatcher.py", > > line 245, in _live_receivers# > for (receiverkey, r_senderkey), receiver in self.receivers:# > File > "/servers/python-environments/discosite/local/lib/python2.7/site-packages/django/dispatch/saferef.py", > > line 121, in remove# > function( self )# > File > "/servers/python-environments/discosite/local/lib/python2.7/site-packages/django/dispatch/dispatcher.py", > > line 270, in _remove_receiver# > with self.lock:# > File > "/servers/python-environments/discosite/local/lib/python2.7/site-packages/gevent/hub.py", > > line 331, in switch# > return greenlet.switch(self) > Now that I look at it this last one seems to be the culprit of the deadlock. I'll file a bug report. André -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/3b1e29a0-6534-4042-9efe-436fcf9b5781%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Database update weirdness
I am developing a game in which the quantity of rebels updates after a turn
change. Rebels are represented as integers from 0 to 100 in the (MySQL)
database.
When I save, this happens:
print world.rebels>>> 0
rebstab = 0
world.rebels += rebstab
world.save()
print world.rebels>>> 0
However, when I use F() expressions (as I gather I should to prevent race
conditions), this happens:
print world.rebels>>> 0
rebstab = 0
world.rebels = F('rebels') + rebstab
world.save()
print world.rebels>>> 100
What's going on?
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/d49909f9-180d-4144-89c5-dcf00bf8f560%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
1.7a1 - Migration syntax error
I am using the following (simplified) model that doesn't migrate using
the new migrations in Django 1.7a1 -
$
$ pip freeze
Django==1.7a1
argparse==1.2.1
distribute==0.6.34
wsgiref==0.1.2
$
$ cat blog/models.py
from django.db import models
from django.utils import timezone
class Blog(models.Model):
title = models.CharField(max_length=200)
created = models.DateTimeField(default=timezone.now())
def __unicode__(self):
return self.title
$
$ python manage.py makemigrations
Migrations for 'blog':
0001_initial.py:
- Create model Blog
$
$ python manage.py migrate
Traceback (most recent call last):
File "manage.py", line 10, in
execute_from_command_line(sys.argv)
File
"/home/pcaulagi/projects/test/local/lib/python2.7/site-packages/Django-1.7a1-py2.7.egg/django/core/management/__init__.py",
line 427, in execute_from_command_line
utility.execute()
File
"/home/pcaulagi/projects/test/local/lib/python2.7/site-packages/Django-1.7a1-py2.7.egg/django/core/management/__init__.py",
line 419, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File
"/home/pcaulagi/projects/test/local/lib/python2.7/site-packages/Django-1.7a1-py2.7.egg/django/core/management/base.py",
line 288, in run_from_argv
self.execute(*args, **options.__dict__)
File
"/home/pcaulagi/projects/test/local/lib/python2.7/site-packages/Django-1.7a1-py2.7.egg/django/core/management/base.py",
line 337, in execute
output = self.handle(*args, **options)
File
"/home/pcaulagi/projects/test/local/lib/python2.7/site-packages/Django-1.7a1-py2.7.egg/django/core/management/commands/migrate.py",
line 62, in handle
executor = MigrationExecutor(connection,
self.migration_progress_callback)
File
"/home/pcaulagi/projects/test/local/lib/python2.7/site-packages/Django-1.7a1-py2.7.egg/django/db/migrations/executor.py",
line 14, in __init__
self.loader = MigrationLoader(self.connection)
File
"/home/pcaulagi/projects/test/local/lib/python2.7/site-packages/Django-1.7a1-py2.7.egg/django/db/migrations/loader.py",
line 48, in __init__
self.build_graph()
File
"/home/pcaulagi/projects/test/local/lib/python2.7/site-packages/Django-1.7a1-py2.7.egg/django/db/migrations/loader.py",
line 145, in build_graph
self.load_disk()
File
"/home/pcaulagi/projects/test/local/lib/python2.7/site-packages/Django-1.7a1-py2.7.egg/django/db/migrations/loader.py",
line 103, in load_disk
migration_module = import_module("%s.%s" % (module_name,
migration_name))
File "/usr/lib/python2.7/importlib/__init__.py", line 37, in
import_module
__import__(name)
File "/tmp/bar/blog/migrations/0001_initial.py", line 17
('created', models.DateTimeField(default=datetime.datetime(2014, 2,
4, 9, 15, 59, 685251, tzinfo=))),
^
SyntaxError: invalid syntax
$
$
What am I missing? I know that we can have use auto_now for the
DateTimeField but I want the value to be shown populated with current
datetime that can be overridden by the user, if they want.
Thanks,
Pradip
--
You received this message because you are subscribed to the Google Groups "Django
users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/52F0B07A.7020203%40gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
Django tests namespace error
Hi guys,
I have django 1.6.1 project which uses django rest framework and I work
around building api. I covered api calls by unittests and I have one
problem.
Application name is 'api' and all tests are passed when I run tests using
command:
python manage.py test api
But when I run all project tests without specifying application name, tests
are failing with error
==
ERROR: test_get_contract_list (someproj.api.tests.ContractAPITestCase)
--
Traceback (most recent call last):
File "/home/user/Projects/someproj/api/tests.py", line 44, in
test_get_contract_list
url = reverse('api:rest_api_contracts')
File
"/usr/local/lib/python2.7/dist-packages/django/core/urlresolvers.py", line
505, in reverse
key)
NoReverseMatch: u'api' is not a registered namespace
In my tests I'm using 'reverse' method from django.core.urlresolvers for
getting urls for tests, for example:
url = reverse('api:rest_api_contracts')
In my root urlconf I have this pattern:
url(r'^api/', include('someproj.api.urls', namespace='api')),
and in my application urlconf:
url(r'^contracts/$', views.ContractListAPIView.as_view(),
name='rest_api_contracts'),
So, why tests are failed when I run it without specifying app name?
Method 'reverse' works fine when I run tests with application name as
parameter and works fine in shell as well.
Regards,
Danil Galeev
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/2aa400f8-ae20-4a23-ba5e-43922985dfc9%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Django - MongoDb failover options for a master-slave setup
Hi All, I'm using MongoDB as back end for my Django web application. I am not sure how to setup an automatic django-mongodb failover mechanism. My requirement is that, when the Primary(master) node of MongoDB is down, the application should automatically switch to Secondary(Slave) node of MongoDB. there's a library called https://pypi.python.org/pypi/django-failover ,but it works only for django 1.3 anyone having any alternative solution for django 1.5 etc ? Thanks. -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/51fd9291-c446-487c-8895-eef50c7bc80c%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Weird deletions in Django
On Tuesday, February 4, 2014 6:37:55 AM UTC, Avraham Serour wrote: > > Sending an email can be faulty, I would use a logger and write the > stacktrace > Also, is it possible that something other than you django application it's > agreeing the database? > I have a forum accessing the database but they have completely separate tables so I can't see how that would affect things. -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/15c69210-b94c-4680-aac7-55b304bb9e75%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Django 1.6.1 not cooperating too well with Gevent
Hello. I have been using Django 1.5.2 + uWSGI + Gevent with no problems for quite some time. I monkey patch my application as soon as I can and the greenlets cooperate with no problems since all the work is network-bound. I have recently tried to switch to Django 1.6.1, but I found that my greenlets started blocking rather frequently. I produced a stacktrace of all the greenlets of a uWSGI worker and realised most of them were blocked around the same lock: 1513 were blocked on: File "/servers/python-environments/discosite/local/lib/python2.7/site-packages/gevent/greenlet.py", line 327, in run result = self._run(*self.args, **self.kwargs) File "/servers/python-environments/discosite/local/lib/python2.7/site-packages/django/core/handlers/wsgi.py", line 206, in __call__ response = self.get_response(request) File "/servers/python-environments/discosite/local/lib/python2.7/site-packages/django/core/handlers/base.py", line 90, in get_response response = middleware_method(request) File "/servers/python-environments/discosite/local/lib/python2.7/site-packages/django/contrib/sessions/middleware.py", line 12, in process_request request.session = engine.SessionStore(session_key) File "/servers/python-environments/discosite/local/lib/python2.7/site-packages/django/contrib/sessions/backends/cache.py", line 14, in __init__ self._cache = get_cache(settings.SESSION_CACHE_ALIAS) File "/servers/python-environments/discosite/local/lib/python2.7/site-packages/django/core/cache/__init__.py", line 135, in get_cache signals.request_finished.connect(cache.close) File "/servers/python-environments/discosite/local/lib/python2.7/site-packages/django/dispatch/dispatcher.py", line 116, in connect with self.lock: File "/servers/python-environments/discosite/local/lib/python2.7/site-packages/gevent/hub.py", line 331, in switch return greenlet.switch(self) 14 were blocked on: File "/servers/python-environments/discosite/local/lib/python2.7/site-packages/gevent/greenlet.py", line 327, in run result = self._run(*self.args, **self.kwargs) File "/servers/python-environments/discosite/local/lib/python2.7/site-packages/django/http/response.py", line 308, in close signals.request_finished.send(sender=self._handler_class) File "/servers/python-environments/discosite/local/lib/python2.7/site-packages/django/dispatch/dispatcher.py", line 184, in send for receiver in self._live_receivers(sender): File "/servers/python-environments/discosite/local/lib/python2.7/site-packages/django/dispatch/dispatcher.py", line 242, in _live_receivers with self.lock: File "/servers/python-environments/discosite/local/lib/python2.7/site-packages/gevent/hub.py", line 331, in switch return greenlet.switch(self) One was blocked on: File "/servers/python-environments/discosite/local/lib/python2.7/site-packages/gevent/greenlet.py", line 327, in run# result = self._run(*self.args, **self.kwargs)# File "/servers/python-environments/discosite/local/lib/python2.7/site-packages/django/http/response.py", line 308, in close# signals.request_finished.send(sender=self._handler_class)# File "/servers/python-environments/discosite/local/lib/python2.7/site-packages/django/dispatch/dispatcher.py", line 184, in send# for receiver in self._live_receivers(sender):# File "/servers/python-environments/discosite/local/lib/python2.7/site-packages/django/dispatch/dispatcher.py", line 245, in _live_receivers# for (receiverkey, r_senderkey), receiver in self.receivers:# File "/servers/python-environments/discosite/local/lib/python2.7/site-packages/django/dispatch/saferef.py", line 121, in remove# function( self )# File "/servers/python-environments/discosite/local/lib/python2.7/site-packages/django/dispatch/dispatcher.py", line 270, in _remove_receiver# with self.lock:# File "/servers/python-environments/discosite/local/lib/python2.7/site-packages/gevent/hub.py", line 331, in switch# return greenlet.switch(self) The lock is a Gevent lock so other Greenlets are free to run. Did something change from Django 1.5 to Django 1.6 that would cause this? It seems to be related to sessions, and I use a memcached cache backend for session storage with Pickle serialization, did the memcached driver change? Best regards and thanks for the help, André Cruz -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/ac22099a-7225-4bb6-81ff-3b6ee796e15f%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
